lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Converting...to svn? [Was: Savannah status]


From: Vaclav Slavik
Subject: Re: [lmi] Converting...to svn? [Was: Savannah status]
Date: Tue, 02 Jun 2009 09:39:44 +0200

Hi,

On Tue, 2009-06-02 at 00:26 +0000, Greg Chicares wrote:
> I can easily see several clear advantages of moving from cvs to svn.
> But, although I've spent a few hours here and there reading about
> DVCSs, I've never noticed any reason why they'd be better for lmi.
> What am I missing?

DVCS helps when changes propagate to upstream repository slowly or
aren't going to be accepted at all. A DVCS allows you to easily maintain
your changes locally and at the same time trivially sync with upstream
(with a centralized VCS, you can achieve that only with private branches
on the server side).

A good example of the latter would be Vadim's MSVC patchset. My recent
work on XSL-FO fixes is a good example of the former: I created a
working "work-xsl-fo-fixes" bzr branch locally and committed my patches
to it as I was sending them to you. This allowed me to split the changes
into smaller independent chunks. If I used a CVS checkout, I'd end up
with a huge mess of interleaved changes that would be hard to separate
and commit. When you decided to postpone the fop-0.95 upgrade, I simply
set the branch aside and forgot about it. I can return to it anytime and
there won't be any uncommitted changes that I'd have to make sense of
first. If I needed to do some unrelated work that depended on these
changes (XSL-FO is a poor example for that, xmlwrapp upgrade is better),
I could base my new work branch on work-xsl-fo-fixes and still be able
to produce diffs that contain only relevant changes. If Vadim needed my
XSL-FO changes, I could easily push my work-xsl-fo-fixes repository to
him -- with history of individual commits, that's better than sending a
huge diff. If he made some more changes, he could send them back to me
just as easily.

In short, it does make our lives a bit easier -- enough for us to create
a bzr mirror.

On the other hand, using Subversion for the central repository has an
advantage for DVCS users too: it's the common ground that DVCSs tend to
support and so you are free to use your favorite DVCS tool instead of
having to use whatever the upstream choose. I'm not sure about hg, but
bzr and git both provide bidirectional interoperability with SVN: you
can branch off central SVN repository, work with your local branch(es)
in the usual DVCS way with all its advantages and then push your changes
back to SVN. 

BTW, DVCSs are useful in our current situation too: if we were using,
say, bzr instead of CVS, each of us would have full replica of the main
repository and restoring it would be trivial. 

Regards,
Vaclav





reply via email to

[Prev in Thread] Current Thread [Next in Thread]