Re: Git vs SVN (was: Can we improve things?)

[Olav Vitters <olav bkor dhs org>]

On Sat, Sep 08, 2007 at 02:03:20AM +0300, Zeeshan Ali wrote:
> Hi!
> 
> On 9/7/07, Olav Vitters <olav bkor dhs org> wrote:
> > On Fri, Sep 07, 2007 at 11:57:19AM +0300, Zeeshan Ali wrote:
> > >    About the svn access, all centralized VCS's are meant for
> > > dictatorships. If the gnome foundation really wants to improve the
> > > situation, i recommend moving to git or some other non-distributed VCS
> > > instead of brain-dead centralized svn for the following reason:
> >
> > This will take 12x longer than fixing the problem. We'll end up with a
> > workaround (as someone still finally has to commit).
> 
>    How come? The developer with write-access to the main repo (who is
> acting as the proxy) would get the commits pushed to his repo from the
> other developer and he would just push them upstream along with his
> commits. As me and Kalle tried to point out, with git you have a lot
> of freedom to do things in many different ways, which isn't true about
> SVN.

This is a workaround. You have developers who only do small patches
against every module. Such a developer 

I agree that it would be easier if it existed. However, it doesn't and
it is a workaround.

> > Finally, people can
> > already use a D-SCM together with SVN (git/bzr/.. support SVN). So if
> > D-SCM would solve things, there wouldn't be an issue currently.
> 
>   As I mentioned in one of my previous emails, the problem would have
> been far too small to make a big fuss about it if either A. it was a
> matter of a git repo instead of an SVN repo or B. the proxy developer
> and the developer needing write access, had decided to use git
> together with git-svn at their end.

I fully agree. But it still doesn't solve the issue (only makes it
easier)... again, this is D-SCM vs client-server, while the issue is
providing access to the central repos.

> > > 1. Developers can clone the main repo and the maintainers (people with
> > > write-access) can just pull from their cloned repos. This way a
> > > developer won't really need write access and he'll just keep on
> > > committing his changes to his repo and inform the maintainer(s) about
> > > his newest cool changes and the maintainer(s) can pull those changes
> > > if they like/need them.
> >
> > I call that a workaround. The problem is the access to the main repos.
> > If the maintainer doesn't pull from every developer you end up with the
> > same problem. At one point someone needs to do something (give access to
> > something / pull).
> 
>    The developer doesn't necessarily need to 'pull'. What you are
> addressing is just one of the many ways things can operate when Git is
> being used. Please read above. I mentioned at least two different
> modes of operation which are not mutually exclusive.

My main point is that the developer still doesn't have access to the
central repos. Nice, a maintainer can setup another repos and have some
way to to give access to the developer to commit there. It doesn't solve
the issue.

> > > 2. #1 is a generic advantage of using a non-distributed VCS but the
> > > reason i would go for git is speed: it's amazingly super fast in all
> > > it's operations and will save a lot of precious developer time.
> >
> > You are ignoring the drawbacks and that it won't solve this issue.
> 
>    For example?

git?. windows support for once, but that is not my problem with
suggesting that Git solves creating accounts.

A developer will need to ask to each maintainer if he would people grant
him access in some way to have him commit to the maintainers git repos
(which might just be some local thing).

> > I am all for D-SCM, but it is not a hammer.
> 
>   That might be but they are much better than centralized SCMs, at
> least git is quite obviously superior to SVN.

In some ways, and worse in others.. even the Git vs SVN page points that
out.

> > > 3. No need to maintain two levels of changelog.
> >
> > That is not true. The ChangeLog requirement has been discussed before.
> > Suggest to read the archives for that discussion (here / d-d-l).
> 
>    I searched the archive and topics of the mails i found, didn't seem
> relevant so it would be nice if you either provide me a link to the
> thread or summarize the conclusion. We are using SVN so ChangeLog
> requirement obviously makes sense but I can't imagine it making any
> sense at all in D-SCMs especially git since i can always get the
> changelog using `git log`.

You can always use 'svn log' as well. The main point is that 'oops, made
a typo' will appear in 'svn log', not in ChangeLog. That is why
ChangeLog is a requirement for some modules in SVN (others don't care).

> > > For details on why a good and
> > > self-respecting developer wouldn't ever consider using svn over git,
> > > you have to watch this presentation by Linus:
> > > http://video.google.com/videoplay?docid=-2199332044603874737 .
> >
> > Last time I watched this it only talked about the benefits of a
> > distributed SCM vs non-distributed SCM. Further, the style of presenting
> > is very flame-ish. It only serves as advocacy to perhaps try some other
> > D-SCM.
> 
>   You need to look at it a bit objectively. Linus says "you are stupid
> and ugly" because you truly are stupid if you prefer to use SVN or any
> centralized SCM and he clearly points out most of the reason why this
> it the honest truth.

Don't call people stupid because they have a different opinion. See
http://live.gnome.org/CodeOfConduct. SVN has its benefits over Git,
that shouldn't be ignored (see the SVN vs Git link posted by Kevin).

My point is that he talking mostly about any D-SCM, not about Git. I see
the benefit of D-SCM over non-D-SCM (client-server/central/whatever).
However, that is different from Git vs bzr/hg/.. , and it is also
different from the problem, slow account setup.

> > Btw, generalising my arguments against git to 'sucky UI' is
> > a misrepresentation.
> 
>    I won't commit that mistake but i didn't really see any other
> convincing argument either. :)

It was about providing accounts to a repos, Git wouldn't have solved it. 

-- 
Regards,
Olav