moving to svn?

Just wondering: Is there any plan to move to svn? I would love to have
a diff command that works when I am offline :slight_smile:

Best Regards,
Rafael

Rafael,

Just wondering: Is there any plan to move to svn? I would love to have
a diff command that works when I am offline :slight_smile:

Its been discussed from time to time. I would like to see this as well,
but for an additional reasons: simpler branch management and faster
updates, etc. SVN handles directories better and merging head to/from a
branch is much easier (no tagging required because it remembers the
merges).

Unfortunately, this is a pretty big change. The main issues are:
1. retention of original log
2. converting the post-commit scripts
3. Subversion isn't fully distributed and if we're going to change, is
SVN really the
   best choice?

Reid.

Its been discussed from time to time. I would like to see this as well,
but for an additional reasons: simpler branch management and faster
updates, etc. SVN handles directories better and merging head to/from a
branch is much easier (no tagging required because it remembers the
merges).

I'm not sure what you mean here by merge tracking but merge tracking
in SVN is under development but not yet complete or available in a
supported release.

Chris

Reid Spencer wrote:

Rafael,

Just wondering: Is there any plan to move to svn? I would love to have
a diff command that works when I am offline :slight_smile:

Its been discussed from time to time. I would like to see this as well,
but for an additional reasons: simpler branch management and faster
updates, etc. SVN handles directories better and merging head to/from a
branch is much easier (no tagging required because it remembers the
merges).

Unfortunately, this is a pretty big change. The main issues are:
1. retention of original log
2. converting the post-commit scripts
3. Subversion isn't fully distributed and if we're going to change, is
SVN really the
   best choice?

Look into tailor (http://darcs.arstecnica.it/). It works well with
converting repositories as well as running those repos in parallel until
the official cutover. Granted, you might need darcs to pull the current
version out of its repo, since it was originally designed with darcs in
mind. Nonetheless, it works rather well.

-scooter

Its been discussed from time to time. I would like to see this as well,
but for an additional reasons: simpler branch management and faster
updates, etc. SVN handles directories better and merging head to/from a
branch is much easier (no tagging required because it remembers the
merges).

Yes. This is very nice. Atomic commits are also usefull for finding
the patch that introduced or fixed a bug.

Unfortunately, this is a pretty big change. The main issues are:
1. retention of original log
2. converting the post-commit scripts
3. Subversion isn't fully distributed and if we're going to change, is
SVN really the
   best choice?

I have just created a copy of the llvm-gcc repository using svk and I
like it! It should also be easier to move from cvs to svn then to git
for exemple.

Reid.

Rafael

> Its been discussed from time to time. I would like to see this as well,
> but for an additional reasons: simpler branch management and faster
> updates, etc. SVN handles directories better and merging head to/from a
> branch is much easier (no tagging required because it remembers the
> merges).
>

I'm not sure what you mean here by merge tracking but merge tracking
in SVN is under development but not yet complete or available in a
supported release.

Sure, the full merge tracking functionality isn't available (yet), but
its definitely easier to keep track of with subversion. In any event,
its not likely to change in the near future. I suppose this could be a
topic for LLVM Conference 2007 :slight_smile:

Reid.

Hello, Scott.

the official cutover. Granted, you might need darcs to pull the current
version out of its repo, since it was originally designed with darcs in
mind.

I can confirm, that tailor converts LLVM CVS with all history preserved
to mercurial repository without any visible troubles.

svnmerge.py makes it easy. [ SvnBranch - GCC Wiki ]

Reid Spencer <rspencer@reidspencer.com> writes:

Its been discussed from time to time. I would like to see this as well,
but for an additional reasons: simpler branch management and faster
updates, etc. SVN handles directories better and merging head to/from a
branch is much easier (no tagging required because it remembers the
merges).

SVN does no keep track of merges.

Unfortunately, this is a pretty big change. The main issues are:
1. retention of original log

No problem. cvs2svn and tailor will keep full log info.

2. converting the post-commit scripts
3. Subversion isn't fully distributed and if we're going to change, is
SVN really the
   best choice?

Others mentioned svk, which is compatible with svn and is fully
distributed. However, if distributed VCS is really interesting for
you, I highly recommend Mercurial:

http://www.selenic.com/mercurial/wiki/index.cgi

BTW, tailor works nicely for converting CVS repos to Mercurial.

Anton Korobeynikov wrote:

the official cutover. Granted, you might need darcs to pull the current
version out of its repo, since it was originally designed with darcs in
mind.

I can confirm, that tailor converts LLVM CVS with all history preserved
to mercurial repository without any visible troubles.

I'm not sure if I just took HEAD or converted the whole llvm repo.
Personally, I like darcs for the atomic theory of patches. YMMV.

Nonetheless, I track llvm's repo via tailor and I do keep the history as
it evolves. If I were permitted to run a webserver outside the corporate
firewall, I'd demonstrate a cvs-svn tailor-ized repo.

-scooter

Anton Korobeynikov wrote:
>>the official cutover. Granted, you might need darcs to pull the current
>>version out of its repo, since it was originally designed with darcs in
>>mind.
>
> I can confirm, that tailor converts LLVM CVS with all history preserved
> to mercurial repository without any visible troubles.

I'm not sure if I just took HEAD or converted the whole llvm repo.
Personally, I like darcs for the atomic theory of patches. YMMV.

DARCS is ridiculously slow on large repositories.

SVN is usable.
Mercurial is usable, though if you try to keep a lot branches in a
single repository space, it will fall down right now because it
creates at least one file in the repo per file in the tree (this would
require close to 400k files for gcc , IIRC:P). This is typical of
most distributed systems, contrary to the claims that they easily
support centralized models.

At least in mercurial, this is easy to fix because of how the
repository format works (it would probably take about 6 weeks of
engineer time ).

Bottom line:
If your goal is a distributed VCS use Mercurial
If your goal is a centralized VCS, use SVN

Bias: I am a subversion developer, and responsible for moving GCC from
CVS to SVN :slight_smile:

I use SVK to track GCC nowadays, and find it quite easy. However, I
still don't believe GCC would work in a project if we didn't have a
centralized server with a single namespace/repository for all
branches. This does not, of course, mean it can't be a mercurial
server in a few years. :slight_smile:

I'm not sure if I just took HEAD or converted the whole llvm repo.
Personally, I like darcs for the atomic theory of patches. YMMV.

I have used darcs to work with psi. It looks like a very clean design,
but currently it is a very anemic implementation IMHO. I constantly
find myself trying to find out how to do a relatively simple task.

Git is fast and has a lot of features, but eats hard disk for lunch :slight_smile:

In the end, I think that the best option now would be to move to svn.
If we want to move to another SCM system latter on, the move should be
much simpler then the cvs -> svn move.

Another wonderful feature of svn: each commit generates a single email
to llvm-commits :slight_smile:

Nonetheless, I track llvm's repo via tailor and I do keep the history as
it evolves. If I were permitted to run a webserver outside the corporate
firewall, I'd demonstrate a cvs-svn tailor-ized repo.

-scooter

Rafael

To (mis)quote a colleague, "All version control systems suck, but <foo>
sucks less." (my appologies to Mike Elkins)

darcs works for me. darcs sucks less.

Before this devolves into another "my vcs is is bigger, better, faster
and has whiter teeth" rat hole, I was merely pointing out that there are
ways to convert the current CVS repo intact.

Frankly, converting to svn means that I merely have to edit my tailor
configuration.

Daniel Berlin wrote:

Perhaps someone could come up with a list of different versioning
software, list the pros and cons, and then we could vote? (Has anyone
mentioned Bitkeeper yet? :slight_smile:

-bw

Bill Wendling wrote:

Perhaps someone could come up with a list of different versioning
software, list the pros and cons, and then we could vote? (Has anyone
mentioned Bitkeeper yet? :slight_smile:

From the maker of SLOCCOUNT: Comments on Open Source Software / Free Software (OSS/FS) Software Configuration Management (SCM) / Revision-Control Systems

Nick

I vote for staying with CVS or moving to SVN, but there's just not that much wrong with the CVS repository now that warrants switching. Offline diffing would be nice, but is not crucial to development. As for random non-cvs, non-svn version control systems, I'm casting a "no" vote since that would require that I install yet more software and learn yet another version control system.

Nate

There are a couple reasons we are using CVS still:

1. CVS works and is well understood by all involved.
2. The main deficiencies of CVS don't impact us much (we aren't
    hampered by lack of atomic commits, renames, and better branch
    facilities).
3. The CVS server is hosted at Illinois. You will have to get buy in from
    them and a volenteer with access to the machine to do the upgrade work
    (including converting the post-commit hooks, etc).
4. I maintain that a real distributed VCS would be very useful for LLVM,
    perhaps moreso than the other features provided by new VCS's. Last
    time this came up, the available distributed vcs's all had serious
    issues. Perhaps mercurial is 'there now'. I don't know.

Personally, I don't really care which VCS we use. I use SVN with the llvm-gcc stuff and it works fine. CVS works fine. I'm sure that, with enough beating on it, some other system would work fine.

-Chris

Hi Chris,

2. The main deficiencies of CVS don't impact us much (we aren't
hampered by lack of atomic commits, renames, and better branch
facilities).

If people would like to see the logical `patch set' that made up a CVS
commit then cvsps may be useful, or, as others have said, use Tailor to
convert to a local repos. in your preferred format.

    http://www.cobite.com/cvsps/
    Darcs - RelatedSoftware/Tailor

4. I maintain that a real distributed VCS would be very useful for
LLVM, perhaps moreso than the other features provided by new VCS's.
Last time this came up, the available distributed vcs's all had
serious issues. Perhaps mercurial is 'there now'. I don't know.

Bazaar, from Canonical -- the same people as behind Ubuntu, has been
concentrating on performance recently. It may be worth keeping an eye
on for the future. I expect it will gain quite a large market share
over time.

    http://bazaar-vcs.org/
    RcsComparisons - wiki.bazaar.canonical.com

Cheers,

Ralph.

Perhaps code.google.com svn? The only thing that can be a problem is
the lack of support for commit scripts.

I'm not certain if this was a serious suggestion. Probably not. I'll actually comment on this one because we actually do use BitKeeper in my research group.

It's a great tool, but it is not free anymore for open-source projects. Branching and merging is a breeze in BitKeeper, has atomic commits, changesets, is completely designed for distributed development (a developer has complete access to all version control information on their local checkout of the repository without being connected to the Internet), and so on.

It also costs a lot, probably more than any version control software out there. Although I cannot disclose how much we pay for it (and we have an academic license), if you came up with a figure in your head and multiplied it by two that would probably be far less than how much it costs to pay for a 1 year lease of BitKeeper. That said, it is a great tool.