SVN (?) Migration

I'd like to stir the pot a bit because this is a topic more than
worth stirring.

Have we considered using git to track llvm development? I've
been playing around with it on a hobby project of mine and it's
quite fantastic. Miles ahead of SVN.

It strikes me that a compiler is just the type of big, complex
project git was designed to handle. We've got subsystem
maintainers just like the linux kernel and the ability to pull
and push from subsystem repositories and cherry-pick individual
commits is very valuable.

For me, the ability to work offline in a distributed fashion is
pretty much a requirement now. It's not been a pleasant experience
doing this regalloc refactoring while trying to track the interface
changes on mainline. With git I'd just create my own private branch,
commit as necessary to my local repository, do merges from upstrema
when I need to and cherry-pick my diffs to send upstream as patches.
This is practically impossible with CVS or SVN. Plus it would be
easier for the llvm integrators to take my e-mail patches and add
them to mainline and keep full revision history.

So I want to pose the question. Should we consider git instead
of SVN?

                             -Dave

So I want to pose the question. Should we consider git instead
of SVN?

There was much debate about which version control system to switch to (please search the llvm-dev mailing list). Git was mentioned and discussed. The end decision was to use SVN.

I think its best not to rehash this discussion. We have already begun the steps to convert to SVN.

There is no perfect version control system that pleases everyone.

-Tanya

Tanya M. Lattner wrote:

There was much debate about which version control system to switch to
(please search the llvm-dev mailing list).

Well, I would if it were searchable...

I think its best not to rehash this discussion. We have already begun the
steps to convert to SVN.

I come from a different perspective. While I understand that we
don't want to constantly revisit decisions, it's not helpful either
to never revisit them.

There is no perfect version control system that pleases everyone.

That's true of practically everything. Yet it is also true that
some systems are better than others. Git is particularly good in
the area of branching and merging which seems to me to be a core
part of what an SCM system is.

I certainly don't want to cause unnecessary frustration. I'm just
raising the question. If the community decides it's been settled
for now, then that's what we've decided. But I don't think it's
good to completely close down the possibility of alternatives
either, especially if new information becomes available.

                        -Dave

David A. Greene schreef:

Git is particularly good in the area of branching and merging

Git isn't very good at merging, it just has much better merging as cvs and svn. If you are
after good merge algos[1] you'd want mercurial of monotone, not git.

regards,

Koen

[1] Or just look at them at http://revctrl.org :slight_smile:

> There is no perfect version control system that pleases everyone.
>
That's true of practically everything. Yet it is also true that
some systems are better than others. Git is particularly good in
the area of branching and merging which seems to me to be a core
part of what an SCM system is.

On the other hand, the Developer Policy says "Once the design of the
new feature is finalized, the work itself should be done as a series
of incremental changes, not as a long-term development branch." and
"In the LLVM project, we do all significant changes as a series of
incremental patches. We have a strong dislike for huge changes or
long-term development branches."

I certainly don't want to cause unnecessary frustration. I'm just
raising the question. If the community decides it's been settled
for now, then that's what we've decided. But I don't think it's
good to completely close down the possibility of alternatives
either, especially if new information becomes available.

I don't think there is any new information. The discussion for
switching to SVN was fairly recent, and a significant amount of effort
has been expended toward executing the switch.

Certainly there may be discussion again later, just like there was for
this switch. In the mean time, sticking with the decision is
worth-while. Version control seems to be one of those topics that
could be endlessly debated by the proponents of the various options,
to the detriment of real work.

~ Scott McMurray

Unfortunately, we already discussed this quite a bit before we settled on SVN. Git does have several nice features, but SVN is both widely available/known and also fairly feature rich. Though not as nice as some of the git features, SVN does have SVK, which allows some distributed development. Further, the transition to SVN is already underway, though the cutover date has been recently moved back to June, to not destabilize the release:
http://llvm.org/SVNMigration.html

-Chris

FYI, try using google with the 'site:http://lists.cs.uiuc.edu/pipermail/llvmdev’ term added.