Re: Possible Transition from SVN to Git?
On 09/01/2008, Simon Ruggier <simon80@gmail.com> wrote:
> On 1/8/08, Eddy Petrișor <eddy.petrisor@gmail.com> wrote:
> > 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.
> >
> > > 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.
>
> The following page is informative:
> http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
This is *not* what I was referring to. I was thinking in the terms of
"a clear recipe that should work for both git or svn in the context of
the team". I would rather have a recipe that makes the VCS transparent
altogether, but, unfortunately, this is not possible and it looks like
it would take a lot of work to do it.
Besides that, the newcomer should be pointed to the right
documentation about the VCS itself.
> > 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.
>
> I don't actually know what mr is, and I haven't been able to find it
> anywhere, so perhaps someone can explain what it is?
http://packages.debian.org/sid/mr
> It seems to me that it would be better in the long term to abstract
> out whatever is common in the -buildpackage utilities into one
> frontend, with backend implementations for each VCS.
That was the idea behind my mail. The biggest problem is that every
*-buildpackage has its own philosophy and has the underlying VCS
syntax and paradigms showing up all over the place.
> The biggest practical advantage that I can see with using git for
> packaging would be that people might commit more often, leading to
> more fine-grained changesets. I'm guessing branches don't need to
> happen often here, so it doesn't seem very compelling to put a lot of
> effort into switching, even though I personally would pick git over
> svn in general.
Like with any hype, I prefer to let things settle for a while. I heard
similar arguments with arch, mercurial, darcs and monotone, but in my
experience darcs was the only one that had such a clean and simple
interface that it was a pleasure working with it (until it spun out of
control when it tried to combine overlapping patches).
I am a happy committer and, sometimes, when working offline I
initiallize a darcs repo over a svn working copy so that I am be able
to work in a sane way. I plainly understand the benefits of often
commits, but in spite of this my main worry is not the git interface
or its documentation, but the discrepancies that might appear once we
decide to use more than one vcs and once each package gets its own
repo, making full "checkouts" and game-repo-wide changes a pain.
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
Reply to: