www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: Zone for scm experiments (Was: Subversion vs other source control systems)
Date Thu, 10 Apr 2008 14:27:28 GMT
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 <jukka.zitting@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/


Mime
View raw message