You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Jukka Zitting <ju...@gmail.com> on 2008/04/09 23:22:59 UTC
Zone for scm experiments (Was: Subversion vs other source control systems)
Hi,
On Wed, Apr 9, 2008 at 10:06 AM, Jukka Zitting <ju...@gmail.com> wrote:
> It would be cool to have a few such examples to gather more experience
> on the related workflows. Could we for example set up some git-svn
> mirrors of selected projects for people to play with? Github looks
> nice for such purposes, and I also have a spare server we could use if
> we want more control over the interaction with Apache svn.
As discussed today in the SCM BOF here in Amsterdam, it would probably
make more sense to do such experiments on Apache hardware if possible.
Would it be OK to create a Solaris zone for such purposes?
I'm aware of the concerns about introducing new systems even
experimentally. For example if people start relying on such git-svn
mirrors, they might easily become perceived as official parts of ASF
infrastructure. How could we best avoid that?
BR,
Jukka Zitting
Re: Zone for scm experiments (Was: Subversion vs other source control systems)
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Henning Schmiedehausen <he...@apache.org> wrote:
> Good, so I consider my mission accomplished. I am
> looking forward to toy
> with git.
>
> Question: How do the svn mirrors rebase for commits.
> As they are
> probably read-only, how do commits on trees loaded
> from the mirror end
> up in the main tree.
We proxy them to the master and immediately replay
them
to mirror, I think (Justin will certainly correct me
if I'm wrong).
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Zone for scm experiments (Was: Subversion vs other source control
systems)
Posted by Henning Schmiedehausen <he...@apache.org>.
Good, so I consider my mission accomplished. I am looking forward to toy
with git.
Question: How do the svn mirrors rebase for commits. As they are
probably read-only, how do commits on trees loaded from the mirror end
up in the main tree.
Best regards
Henning
Jukka Zitting schrieb:
> Hi,
>
> On Fri, Apr 11, 2008 at 12:30 PM, Justin Erenkrantz
> <ju...@erenkrantz.com> wrote:
>> FTR, I just talked to Jukka here in Amsterdam - the purpose of the
>> zone seemed to be to host a copy of our SVN repository. I indicated
>> that with the new EU SVN mirror coming online Real Soon Now(tm) and
>> the pending replacement of eris (within ~3-4 months) - that we should
>> be able to ease some of the DDoS restrictions on our SVN servers that
>> should let svn-git and other tools get what they need.
>>
>> So, as I see things, we do *not* need to create a zone at this time.
>> If there does come to a point where a zone makes sense, then we can
>> figure out what it'd be used for first. But, for now, I don't see the
>> need. Jukka, if I'm mistaken, please let me know.
>
> Sounds good to me.
>
> With the new SVN mirror we should be able to let people run tools like
> git-svn directly against svn without needing an extra git mirror. We
> can reconsider if it turns out that git-svn will still put too much
> load against svn.
>
> BR,
>
> Jukka Zitting
Re: Zone for scm experiments (Was: Subversion vs other source control systems)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Apr 11, 2008 at 12:30 PM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> FTR, I just talked to Jukka here in Amsterdam - the purpose of the
> zone seemed to be to host a copy of our SVN repository. I indicated
> that with the new EU SVN mirror coming online Real Soon Now(tm) and
> the pending replacement of eris (within ~3-4 months) - that we should
> be able to ease some of the DDoS restrictions on our SVN servers that
> should let svn-git and other tools get what they need.
>
> So, as I see things, we do *not* need to create a zone at this time.
> If there does come to a point where a zone makes sense, then we can
> figure out what it'd be used for first. But, for now, I don't see the
> need. Jukka, if I'm mistaken, please let me know.
Sounds good to me.
With the new SVN mirror we should be able to let people run tools like
git-svn directly against svn without needing an extra git mirror. We
can reconsider if it turns out that git-svn will still put too much
load against svn.
BR,
Jukka Zitting
Re: Zone for scm experiments (Was: Subversion vs other source control systems)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Apr 9, 2008 at 11:22 PM, Jukka Zitting <ju...@gmail.com> wrote:
> As discussed today in the SCM BOF here in Amsterdam, it would probably
> make more sense to do such experiments on Apache hardware if possible.
> Would it be OK to create a Solaris zone for such purposes?
>
> I'm aware of the concerns about introducing new systems even
> experimentally. For example if people start relying on such git-svn
> mirrors, they might easily become perceived as official parts of ASF
> infrastructure. How could we best avoid that?
FTR, I just talked to Jukka here in Amsterdam - the purpose of the
zone seemed to be to host a copy of our SVN repository. I indicated
that with the new EU SVN mirror coming online Real Soon Now(tm) and
the pending replacement of eris (within ~3-4 months) - that we should
be able to ease some of the DDoS restrictions on our SVN servers that
should let svn-git and other tools get what they need.
So, as I see things, we do *not* need to create a zone at this time.
If there does come to a point where a zone makes sense, then we can
figure out what it'd be used for first. But, for now, I don't see the
need. Jukka, if I'm mistaken, please let me know.
Thanks. -- justin
Re: Zone for scm experiments (Was: Subversion vs
other source control systems)
Posted by Santiago Gala <sa...@gmail.com>.
El jue, 10-04-2008 a las 17:04 +0200, Henning Schmiedehausen escribió:
> Santiago Gala schrieb:
> > El jue, 10-04-2008 a las 09:31 +0200, Henning Schmiedehausen escribió:
>
> >> IMHO there will be no non-svn commits (yet?). This will be strictly one
> >> way from svn -> git. Putting commits back into SVN will be IMHO by
> >> applying patches.
> >>
> >
> > I am committing using "git svn dcommit" already. I don't think it is
> > easy to notice, actually, unless I start using git "style" for commit
> > messages, which I actually did yesterday:
>
> These are svn commits in disguise AFAIK. So you use the git frontend but
> it actually commits using SVN in the back. What I meant is, that there
> is no automatic replication happening from the mirrored git tree to the
> subversion repository but the syncing happens through the client.
>
Ok, I see your point (I was not seeing it). While we have a svn master,
all commits will be "svn commits". I don't think we want to complicate
the setup to have automated syncing beyond a svn commit hook to "git svn
rebase" the "trunk" or "git-svn" branch.
what "git svn dcommit" does is actually take all commits from the
"git-svn" sync point on and commit them to subversion, one at a time,
while rebasing the set. I don't think we want to go beyond this while
svn is "da master".
> > (I applied a patch sent by Dave Johnson to the list, and I thought that
> > the convention of adding Author:/Signed-off-by: headers is a good idea
> > and we already have had comments on this line:
> > http://markmail.org/message/fphkuo3txveiczog and even old times
> > templates for acknowledgement of patches.
>
> that is fine, but this is a project decision, I see no reason to dictate
> any foundation wide policy. PMCs are happy using their own schemes or no
> scheme at all.
>
Well, I'm not sure. Actually recently Henri (not sure) pointed to the
old CVS template, which included, as a policy, the Submitted-by: Headers
to ensure code provenance. This could easily be made into a policy
similar to the "tick box" in JIRA to accept the license. So, to comment
on what you said: "I see a reason: creating an audit trail" I'm much
more comfortable with a header in svn commits than with a tick box in a
proprietary tool which I can't use offline.
> > Basically git svn can deal with subversion commits if the history is
> > kept linear and no merges are done. This is what actually forces
> > continuous rebases, even for your private branches, to keep them updated
> > re: the subversion trunk.
>
> This is something that almost surely will not fly. I anticipate that the
> number of merges will skyrocket with svn 1.5 when it will be much easier
> to merge (Karl Fogel's words ... :-) ) than it is with the current SVN.
> Also, linear history (as I understand it) is something that we have
> because there is a history reluctance to branch and merge (which IMHO
> comes from our CVS history).
>
If svn is better at merging it might even happen git-svn will learn
quickly to do merge dcommits too, I bet. I would write this code if
git-svn was not uncommented perl using an insane subversion API.
> As I wrote before, I see git mainly as an "add on" for offline commits
> and local work. SVN is here to stay for a while.
>
Cool. I have no problems if we use webdav/fsfs to store the patch
sets. :P
> [,,,]
> > I like a lot the ability of doing diffs between versions of branches,
> > having options for move/copy detection and color differences. Where git
> > really shines is for code review or patch integration, IMO.
>
> Can you explain the code review part a bit? I had some exposure to
> Crucible lately and I don't see how code review benefits from git. But
> then again, I might just be thick. :-)
>
(I'm not sure what Crucible is, but if it needs a server does not work
for me in my bus going back home. I spend 25% of my working time
commuting, and I have no car, so I actually work there.)
An invented task, on the fly: see how are we evolving re: dependency of
gmodules.com in shindig. You can see similar "what if" or "audit"
questions all the time in the incubator. Or just, how many dependencies
on such and such modules/api do we have? who introduced them? how is it
evolving? ...
# find how many dependencies on gmodules.com on shindig and assess
git clone git://github.com/sgala/apache-incubator-shindig.git
git grep gmodules.com | wc -l
4 #ok, not many
git grep -l gmodules.com | xargs gedit
# find who removed them and when
git log --color --stat -M -p -Sgmodules.com #use less /gmodules.com ...
# if you like UIs use gitk with the search to do the same
# how many commits touched them?
git log --stat -M -p -Sgmodules.com | egrep ^commit | wc -l
14
(...)
While doing that use a stopwatch and measure times. When you finish,
please, do the same with subversion and the web browsing tools. Try it
while the bus/train goes home, offline or using a slow GPRS connection.
This kind of things was what I was meaning. It is a great set of tools
to study and manage code.
Regards
Santiago
> Best regards
> Henning
>
>
--
Santiago Gala
http://memojo.com/~sgala/blog/
Re: Zone for scm experiments (Was: Subversion vs other source control
systems)
Posted by Henning Schmiedehausen <he...@apache.org>.
Santiago Gala schrieb:
> El jue, 10-04-2008 a las 09:31 +0200, Henning Schmiedehausen escribió:
>> IMHO there will be no non-svn commits (yet?). This will be strictly one
>> way from svn -> git. Putting commits back into SVN will be IMHO by
>> applying patches.
>>
>
> I am committing using "git svn dcommit" already. I don't think it is
> easy to notice, actually, unless I start using git "style" for commit
> messages, which I actually did yesterday:
These are svn commits in disguise AFAIK. So you use the git frontend but
it actually commits using SVN in the back. What I meant is, that there
is no automatic replication happening from the mirrored git tree to the
subversion repository but the syncing happens through the client.
> (I applied a patch sent by Dave Johnson to the list, and I thought that
> the convention of adding Author:/Signed-off-by: headers is a good idea
> and we already have had comments on this line:
> http://markmail.org/message/fphkuo3txveiczog and even old times
> templates for acknowledgement of patches.
that is fine, but this is a project decision, I see no reason to dictate
any foundation wide policy. PMCs are happy using their own schemes or no
scheme at all.
> Basically git svn can deal with subversion commits if the history is
> kept linear and no merges are done. This is what actually forces
> continuous rebases, even for your private branches, to keep them updated
> re: the subversion trunk.
This is something that almost surely will not fly. I anticipate that the
number of merges will skyrocket with svn 1.5 when it will be much easier
to merge (Karl Fogel's words ... :-) ) than it is with the current SVN.
Also, linear history (as I understand it) is something that we have
because there is a history reluctance to branch and merge (which IMHO
comes from our CVS history).
As I wrote before, I see git mainly as an "add on" for offline commits
and local work. SVN is here to stay for a while.
[,,,]
> I like a lot the ability of doing diffs between versions of branches,
> having options for move/copy detection and color differences. Where git
> really shines is for code review or patch integration, IMO.
Can you explain the code review part a bit? I had some exposure to
Crucible lately and I don't see how code review benefits from git. But
then again, I might just be thick. :-)
Best regards
Henning
RE: Zone for scm experiments (Was: Subversion vs othersource control systems)
Posted by "Gav...." <br...@brightontown.com.au>.
> -----Original Message-----
> From: Santiago Gala [mailto:santiago.gala@gmail.com]
> Sent: Thursday, 10 April 2008 10:27 PM
> To: infrastructure-dev
> Subject: Re: Zone for scm experiments (Was: Subversion vs othersource
> control systems)
>
<snip>
>
> I am committing using "git svn dcommit" already. I don't think it is
> easy to notice, actually, unless I start using git "style" for commit
> messages, which I actually did yesterday:
>
> http://github.com/sgala/apache-incubator-
> shindig/commit/278fb812bf7567a0f569cc6e8e4d85782da53736 is
> http://svn.apache.org/viewvc?view=rev&revision=646503
>
> (I applied a patch sent by Dave Johnson to the list, and I thought that
> the convention of adding Author:/Signed-off-by: headers is a good idea
> and we already have had comments on this line:
> http://markmail.org/message/fphkuo3txveiczog and even old times
> templates for acknowledgement of patches.
downstream projects get a better sense of who (to blame/) did what too.
http://www.16degrees.com.au/hudson/job/SimalWebappSVN/266/changes#detail0
I noticed the change in commit style there.
fwiw, Apache Forrest and others do mention the contributor in the log
message and in changes files etc, but this works well too.
Gav...
<snip>
>
> Regards
> Santiago
>
> >
> > Best regards
> > Henning
> >
> >
> >
> --
> Santiago Gala
> http://memojo.com/~sgala/blog/
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.22.11/1368 - Release Date: 4/9/2008
> 4:20 PM
Re: Zone for scm experiments (Was: Subversion vs other
source control systems)
Posted by Santiago Gala <sa...@gmail.com>.
El jue, 10-04-2008 a las 09:31 +0200, Henning Schmiedehausen escribió:
> Hi,
>
> Santiago Gala schrieb:
> > El jue, 10-04-2008 a las 00:22 +0300, Jukka Zitting escribió:
> >> Hi,
> >>
> >> On Wed, Apr 9, 2008 at 10:06 AM, Jukka Zitting <ju...@gmail.com> wrote:
> >>> It would be cool to have a few such examples to gather more experience
> >>> on the related workflows. Could we for example set up some git-svn
> >>> mirrors of selected projects for people to play with? Github looks
> >>> nice for such purposes, and I also have a spare server we could use if
> >>> we want more control over the interaction with Apache svn.
> >> As discussed today in the SCM BOF here in Amsterdam, it would probably
> >> make more sense to do such experiments on Apache hardware if possible.
> >> Would it be OK to create a Solaris zone for such purposes?
> >>
> >> I'm aware of the concerns about introducing new systems even
> >> experimentally. For example if people start relying on such git-svn
> >> mirrors, they might easily become perceived as official parts of ASF
> >> infrastructure. How could we best avoid that?
> >>
> >
> > There is a certain contradiction in the previous two paragraphs: the
> > best way to avoid those experiments being perceived as official parts of
> > infra is doing them outside the hardware. IIRC this was argued and it
> > related to the fact that planetapache.org is not inside ASF hardware.
>
> That is not what I recall. This experiment does not actually use ASF
> hardware directly but a Solaris zone which is better manageable by
> infra. It was already discussed that labs can get a zone, so it should
> also be possible for these experiments.
>
cool, my problem is that it is difficult that something done in
apache.org machines is not perceived as "official parts of ASF
infrastructure", quoting from above. If the infrastructure people is
happy with this balance between control fantasy
( http://www.ckwalsh.com/articles/controlfantasy.htm ) and public
perception I'm happy with it too.
>
> > Other interesting thing is that "mirror" sounds like something stronger
> > that it really is. For instance, *any* git clone that any person makes
> > of the one in git hub is a full copy and can be republished and kept in
> > synchrony with svn, because of the id added to git commits. So there is
>
> Yes, but it idea of having a designated svn-git mirror at the ASF means,
> that we can point the people interested in git to that git repos and
> that it is possible to loosen the restrictions on the svn repo itself
> (mod_dontdothat) for a single machine that might be located in the same
> rack as the svn server.
>
this is "A Good Thing" (TM). Using an authors file with id ->
name/id@apache.org pairs might be cool too. I'm happy to help with my
limited experience re: imports. I have sent a proposal for AC 2008 US
where I would make an introductory talk on how it can help in the
different use case scenarios, and I'm also preparing an academic paper
on concrete usability metrics of different SCM tools for some tasks. So
I'm investing in this area at the moment.
>
> > little value in the mirrors beyond the stable URL, which basically could
> > be, again, reconstructed around the SHA-1 git commit names. Except for
> > non-svn commits, where the need of rebasing the commits changes the
> > SHA-1 all the time :(
>
> IMHO there will be no non-svn commits (yet?). This will be strictly one
> way from svn -> git. Putting commits back into SVN will be IMHO by
> applying patches.
>
I am committing using "git svn dcommit" already. I don't think it is
easy to notice, actually, unless I start using git "style" for commit
messages, which I actually did yesterday:
http://github.com/sgala/apache-incubator-shindig/commit/278fb812bf7567a0f569cc6e8e4d85782da53736 is
http://svn.apache.org/viewvc?view=rev&revision=646503
(I applied a patch sent by Dave Johnson to the list, and I thought that
the convention of adding Author:/Signed-off-by: headers is a good idea
and we already have had comments on this line:
http://markmail.org/message/fphkuo3txveiczog and even old times
templates for acknowledgement of patches.
Basically git svn can deal with subversion commits if the history is
kept linear and no merges are done. This is what actually forces
continuous rebases, even for your private branches, to keep them updated
re: the subversion trunk.
> The first and foremost use case for this will be local (detached)
> commits and the ability for easy local branching (as you did e.g. with
> the Shindig code).
>
I'm doing it a lot, I'm keeping my local changes in branches, etc. It is
a bit confusing but it definitely works.
I like a lot the ability of doing diffs between versions of branches,
having options for move/copy detection and color differences. Where git
really shines is for code review or patch integration, IMO.
> >
> > Re: the BoF, can you please publish some sort of minutes here?
>
> Did that already. :-)
Cool, thanks, and a very thorough summary, I think. Pity I was not
there, a bit frustrated.
Regards
Santiago
>
> Best regards
> Henning
>
>
>
--
Santiago Gala
http://memojo.com/~sgala/blog/
Re: Zone for scm experiments (Was: Subversion vs other source control
systems)
Posted by Henning Schmiedehausen <he...@apache.org>.
Hi,
Santiago Gala schrieb:
> El jue, 10-04-2008 a las 00:22 +0300, Jukka Zitting escribió:
>> Hi,
>>
>> On Wed, Apr 9, 2008 at 10:06 AM, Jukka Zitting <ju...@gmail.com> wrote:
>>> It would be cool to have a few such examples to gather more experience
>>> on the related workflows. Could we for example set up some git-svn
>>> mirrors of selected projects for people to play with? Github looks
>>> nice for such purposes, and I also have a spare server we could use if
>>> we want more control over the interaction with Apache svn.
>> As discussed today in the SCM BOF here in Amsterdam, it would probably
>> make more sense to do such experiments on Apache hardware if possible.
>> Would it be OK to create a Solaris zone for such purposes?
>>
>> I'm aware of the concerns about introducing new systems even
>> experimentally. For example if people start relying on such git-svn
>> mirrors, they might easily become perceived as official parts of ASF
>> infrastructure. How could we best avoid that?
>>
>
> There is a certain contradiction in the previous two paragraphs: the
> best way to avoid those experiments being perceived as official parts of
> infra is doing them outside the hardware. IIRC this was argued and it
> related to the fact that planetapache.org is not inside ASF hardware.
That is not what I recall. This experiment does not actually use ASF
hardware directly but a Solaris zone which is better manageable by
infra. It was already discussed that labs can get a zone, so it should
also be possible for these experiments.
> Other interesting thing is that "mirror" sounds like something stronger
> that it really is. For instance, *any* git clone that any person makes
> of the one in git hub is a full copy and can be republished and kept in
> synchrony with svn, because of the id added to git commits. So there is
Yes, but it idea of having a designated svn-git mirror at the ASF means,
that we can point the people interested in git to that git repos and
that it is possible to loosen the restrictions on the svn repo itself
(mod_dontdothat) for a single machine that might be located in the same
rack as the svn server.
> little value in the mirrors beyond the stable URL, which basically could
> be, again, reconstructed around the SHA-1 git commit names. Except for
> non-svn commits, where the need of rebasing the commits changes the
> SHA-1 all the time :(
IMHO there will be no non-svn commits (yet?). This will be strictly one
way from svn -> git. Putting commits back into SVN will be IMHO by
applying patches.
The first and foremost use case for this will be local (detached)
commits and the ability for easy local branching (as you did e.g. with
the Shindig code).
>
> Re: the BoF, can you please publish some sort of minutes here?
Did that already. :-)
Best regards
Henning
Re: Zone for scm experiments (Was: Subversion vs other source
control systems)
Posted by Santiago Gala <sa...@gmail.com>.
El jue, 10-04-2008 a las 00:22 +0300, Jukka Zitting escribió:
> Hi,
>
> On Wed, Apr 9, 2008 at 10:06 AM, Jukka Zitting <ju...@gmail.com> wrote:
> > It would be cool to have a few such examples to gather more experience
> > on the related workflows. Could we for example set up some git-svn
> > mirrors of selected projects for people to play with? Github looks
> > nice for such purposes, and I also have a spare server we could use if
> > we want more control over the interaction with Apache svn.
>
> As discussed today in the SCM BOF here in Amsterdam, it would probably
> make more sense to do such experiments on Apache hardware if possible.
> Would it be OK to create a Solaris zone for such purposes?
>
> I'm aware of the concerns about introducing new systems even
> experimentally. For example if people start relying on such git-svn
> mirrors, they might easily become perceived as official parts of ASF
> infrastructure. How could we best avoid that?
>
There is a certain contradiction in the previous two paragraphs: the
best way to avoid those experiments being perceived as official parts of
infra is doing them outside the hardware. IIRC this was argued and it
related to the fact that planetapache.org is not inside ASF hardware.
Other interesting thing is that "mirror" sounds like something stronger
that it really is. For instance, *any* git clone that any person makes
of the one in git hub is a full copy and can be republished and kept in
synchrony with svn, because of the id added to git commits. So there is
little value in the mirrors beyond the stable URL, which basically could
be, again, reconstructed around the SHA-1 git commit names. Except for
non-svn commits, where the need of rebasing the commits changes the
SHA-1 all the time :(
Re: the BoF, can you please publish some sort of minutes here?
Regards
Santiago
> BR,
>
> Jukka Zitting
--
Santiago Gala
http://memojo.com/~sgala/blog/