llvm dev - Nov 2006 - [LLVMdev] moving to svn?

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.

-- 
With best regards, Anton Korobeynikov.

Faculty of Mathematics & Mechanics, Saint Petersburg State University.

On 11/27/06, Scott Michel <scottm at rushg.aero.org>
wrote:
> 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 :)

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.  :)


> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

> 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 :-)

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 :-)
> 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