incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Subversion & Git (was: Proposed short term goals)
Date Tue, 14 Jun 2011 15:40:52 GMT
Below, I will refer to the information from:
  http://wiki.services.openoffice.org/wiki/SCM_Migration#Evaluating_the_SCM_candidates.2C_Metrics

(thanks to Meeks for pointing me there)

On Tue, Jun 14, 2011 at 11:28, Mathias Bauer <Mathias_Bauer@gmx.net> wrote:
>
> From our own experience the biggest problem with svn was merging of
> branches.

The above page was written using Subversion 1.4. That was before we
had merge tracking features, and before a number of merge-related
optimizations.

We're now on the cusp of releasing Subversion 1.7. Infrastructure has
been discussing whether to install a build on the server. It
definitely has some faster merging, and much better features.

> We often had features that took several months of development time. We
> didn't want to commit incomplete or buggy code to our master, so we created
> feature branches for them and called them "child workspaces" (cws). When a
> cws was finished, it had to be synchronized with the current master before
> it could be integrated. Developers also might want to merge in changes from
> master into their branch in between so that code change conflicts can be be
> reduced or solved early.

Right. We use the same in the development of Apache Subversion itself.

"svn merge" is used to keep the branch up to date. "svn merge
--reintegrate" to bring it back onto trunk. Merge tracking makes this
much, much easier than when you had to do it (no anchor tag, for
example).

I know that Subversion is slower in some ways from Mercurial or Git, I
believe that the CWS process amplified that problem.

> This merging of branches took hours with svn and was a PITA. With Mercurial
> it usually took only a few minutes and it was done completely on a local
> computer. No problems with slow or interrupted internet connections.

We do the merges on a local computer, too. It is impossible to merge
only on the server (it cannot resolve conflicts).

> Beside that, if you ever worked with a DSCM, you never want to go back to a
> centralized SCM. It's as easy as that. The OOo repo is huge, but with
> Mercurial it took only a few seconds or minutes to create a clone or 10
> minutes to get the source from it. Checking out from svn over http took
> hours. But I'm sure the pros and cons of DSCM are known.

The page from above did not show "hours" for non-Windows developers.
Since that old 1.4 release, we have fixed Windows checkouts. Their
performance is comparable to the Unix-ish platforms.

To be specific, it says a Unix checkout to local disk is a mere 5
minutes. That sounds faster than Mercurial.

[and I'll note that it says a Windows git checkout did NOT even complete]

>
> *If* we had some options, I would like to think about the following ones:
>
> - start with svn and decide later (at least in the next few months we won't
> need feature branches a lot)

This is the only choice available to us at this time.

>
> - have svn for the master and do all work on a git repo elsewhere that at
> times is pushed to the svn master

People use git-svn to do some work, but I seem to recall hearing that
it does not manage the merge-tracking information properly. And that
it may not deal with properties either. I think we would want some
git-svn people to detail any pitfalls if that tool is recommended at
all.

>
> - start with a git repo from the beginning

As stated elsewhere, this is not available right now. There are the
technical issues, and I know that many people also have concerns with
potential community issues. But that is all a discussion for a later
time. Not here and now.

Cheers,
-g

Mime
View raw message