[Lazarus] SubVersion vs Git
florian at freepascal.org
Wed Nov 5 10:50:46 CET 2008
Alexander Klenin schrieb:
> On Wed, Nov 5, 2008 at 18:02, Florian Klaempfl <florian at freepascal.org> wrote:
>> Git is a hype. Git might be nice for projects with >100 developers and
>> which has (like linux) dedicated branch maintainers. Git allows to
>> support complicated project structures with several layers of
>> maintainers and project managers. But this is something smaller projects
>> like FPC or Lazarus don't need.
> I disagree. I, for example, have moved all my Unix-based projects to Git,
> even personal ones, and it is much better to work with even in a
> single-developer case.
> In particular, ability to create commits off-line is very valuable to me.
But what does it help? Nobody sees such a off-line commit. If I work on
different things on subversion, I just copy the repository.
>>> * Git repositories are MUCH smaller.
>> Who did tell you this? Linus? Does he have the history of the Linux code
>> since version 0.1 in his repository?
> Since Git is distributed, the notion of "his" repository is rather vague,
> but such a repository definitely exists:
last change Mon, 4 Apr 2005 16:08:33 +0000
It does not contain all changes made ever to linux as e.g. the lazarus
svn does: the lazarus svn contains _all_ changes made ever to lazarus.
>>> * Git is local, so checking history or doing commits are really fast.
>> I doubt that a repository containing the full lazarus history is smaller
>> than a repository containing each file twice.
> They are usually of about equal size, for example, svn checkout of
> Pidgin (IM tool) is 122 MB while complete history in Git repository is 148 MB.
> But the OP's point was that local operations are MUCH faster,
> so much that it changes the work flow. For example, to show a few last
> log messages
> from the lazarus repository takes me 10-20 sec.,
With TortoiseSVN's cache it's also instantenous for me :)
> and showing a diff between
> to revisions of a file -- another 30-60 sec., while in Git these
> operations are instantaneous.
This is indeed a imo small disadvantage of svn but it doesn't compensate
the huge bureacracy required for a dvcs.
>>> * You have lots of backups of Git repositories because they are local
>>> to each developer. In SubVersion, if the repository server is down,
>>> everybody is stuck.
>> Only with committing. With a DVCS you're also stuck if the repository
>> for the "official" code is dead. Great that you can "commit" to your
>> local repository but nobody will see it so what's the point about it?
> With SVN if the central repository is dead, then
> the whole history of the project vanishes with no chance of restoration.
> Of course, the central repository should be backed up, but still if the failure
> occurs, it is catastrophic.
You need this with git too because nobody ensures that anybody has
really such a copy.
> On the contrary, with DVCS (not only Git) such a failure is just a
> minor inconvenience,
> since each developer has a local copy of the history, and can easily publish it.
It could be that someone has :) Further, it requires that someone
publishes this address and it gets spread. Such thing sounds nice but in
reality I see no value in it.
> Another compelling feature of Git is the possibility to create and manage
> local branches. For example, when I want to add a feature to Lazarus,
> I would like to present it as a series of clean patches for easier review
> and better log history. However, I can not do this with Subversion in
> a practical way,
> so I have to submit first patch of the series, wait for it to get accepted,
> submit the second one etc.
> This wastes both my and reviewer's time so much that it can take months
> instead of weeks to complete a moderately complex feature.
> Actually, I due to this obstacle have given up trying to develop
> more complex features for Lazarus and just submit small patches for
> trivial things ;-)
For this use case we've the mercurial mirror. However, as far as I can
see, nobody uses it for real work. Probably because of the higher
learning curve of a dvcs.
But at least speaking for FPC: anybody interested in FPC development can
get write access to own svn branchs where he can do his development on
FPC. Using svnmerge, merging of such branches is very easy. This has
also the advantage that changes don't get lost in somebody's local
repository either because it might not be backed up as the central svn
or because the submitter forgets about his work. I even consider such a
solution better than a dvcs: the danger of changes being lost is really
low. Of course, this can be done only for smaller projects, but I still
consider FPC/Lazarus small in this regard.
More information about the Lazarus