Re: Possible Transition from SVN to Git?
I saw this thread since it started, but I didn't had the time to
answer. Now i have time to throw in my 2 cents.
On 03/01/2008, Miriam Ruiz <little.miry@gmail.com> wrote:
> After giving some thoughts about having a git or bzr repository in the
> games team, I guess I have a point of view about it. I think it might
> be a good idea to start experimentally handling some packages in git
> (or bzr), as long as:
>
> 1) Someone has to explain briefly but clearly, preferably in a wiki
> page, the minimal steps how to obtain the latest sources from the
> repository and how to upload modifications to them, so that it won't
> be a problem for newbies to join the team. I myself don't know much
> about handling stuff in git or bzr either.
That is a must.
> 2) I'd prefer to experimentally handle just a few packages at first,
> and with just one other system than svn for the moment (not git and
> bzr at once). It might be a good idea to handle some newer packages in
> git just to get an idea about whether it would work or not, but it
> could be OK to move some few packages from svn too anyway if it's
> really wanted. As I said, it should be done in a way that anyone in
> the team would be able to work on them too, that means the wiki page
> and so.
Although I agree with the "one package at a time idea" I disagree to
have some kind of "digital divide" since it can be very confusing for
a new comer to see we maintain a package and they don't find it in our
svn.
I am not saying we shouldn't look at git, bzr, darcs, hg or some other
VCS, but we should be careful to establish first a generic way to
document the way to fetch the source of the package (the tools using
the VCS-* fields and mr might be useful, but note that we have
anonymous URIs for SVN now). The point is to have a simple way to say
to a new developer "fetch the source from VCS with this command"
without forcing him to do detective work to establish what to do to
get that source.
The problem I see is that using two VCS-es (I don't want to think
about using more, since it would be a lot worse) is that it can be
really confusing and can demotivate some person knowing only one of
the two to fix a game using the other VCS[1].
> 3) From what I've seen, the idea might not really be to move to a
> newer versioning system, but to have different repository systems at
> once. I don't really consider this to be a huge problem (as long as
> the basic howto is documented, as I said), but it might make it harder
> to implement ACLs (if desired) in the future or things like that, so
> I'd like to have an open discussion on the pros and cons about having
> one single system vs. multiple ones at some point.
mr might wrap up nicely the two/more vcs-es, but note that we don't
have mr-buildpackage and, generally, *-buildpackage utilities have
different behaviours and interfaces, and one needs to learn each one
individually.
Also, with the addition of DVCS-es and one repo per package for them
(since it seems that most of them are uncapable to do partial
checkouts), to me, it looks like the risk of having
each-package-has-its-own-packaging-policy seems to be higher than with
SVN since you'd have a higher effort to do a "checkout of everything"
to examine inconsistencies.
> 4) If at any point someone would need to download all the packages to
> do some general modification (like that with about the Homepage, for
> example), we could prepare a set of scripts to do so. With some small
> scripts the system should be able to download all the packages from
> the different versioning systems, or upload the changes to all of
> them. Ideas on this?
Although I might sound alarmist, I think we should have this from the
start (and mr looks like the easiest way to do it - do we make another
repo to keep the mrconfig file :-D ? ).
> 5) I'd prefer if similar packages shared the same versioning system
> and repositories, for example all Kenta Cho's games should be handled
> in a similar way, all Quake-related stuff that might be considered to
> be related, and so on.
I agree.
> 6) As Vincent said, each package should be in just one repository. No
> redundancy allowed, as it would only be a source of problems.
I think this should be a really strong rule. If one package migrates
from one to the other, the old VCS should be cleaned up.
> 7) If we move packages from a versioning system to another, I don't
> want their history and logs to be lost. Is it possible to do so?
> Eddy, Gonéri, Sam, Rhonda, any thoughts on this?
is possible via tailor, but it can be painful in some combinations.
> Joey, would you consider joining the Team if we decided to use git?
> What changes in the repository would you suggest to be comfortable
> with? I must say that I personally wouldn't like to have the package
> source out of debian/ in the repositories to be honest, but apart from
> that?
I agree since it would create inconsistency in the source packages,
and since we don't have deb version 2 and wig-and-pen or joey's git
source packages, we still have to be concerned about consistency at
dsc+diff+orig source level.
To conclude, I think we should experiment, but only with individual
packages and we should make sure to create neither inconsistencies
between our packages nor a digital divide within the team based on the
tools we use; rather we should make sure the tools become somewhat
transparent.
[1] I suspect this would happen more often for people knowing SVN,
than the other way around, since is more likely for a person to know
just svn, than to know just git.
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
Reply to: