[LLVMdev] git Status Update?

[Jason Kim]

On Thu, Sep 8, 2011 at 5:09 PM, David A. Greene <dag at cray.com> wrote:

> Bill Wendling <wendling at apple.com> writes:
>
> >> Let's face it, Joe Dragon is pretty much happy with svn and there's an
> >> svn-git bridge for the rest of us.
>
> The svn-git bridge is broken as several people stated before.  It is
> easier to contribute code via the gateway but it causes headaches when
> one updates one's working git clone after submitting through dcommit.
> The git pull generates all kinds of false conflicts.  This is because
> svn doesn't understand git history and never will.
>
> git-svn will never be a replacement for git.
>
> > For me, the question is "why do we *need* to switch our versioning
> > system?". Nothing is broken with our current model.
>
> There are things broken with the current model, though you may not care
> about them.  It is not possible to conveniently keep a private copy of
> LLVM and associated projects and sync regularly with upstream.  It flat
> out sucks.  This is because the svn model is fundamentally opposed to
> the idea of private repositories.  There's One True Repository and
> that's it.
>
>

Err, there are other ways around these issues - At least from mercurial
side, the svn bridge is probably similarly busted, but I avoid those issues
by using  MQ to maintain a set of patches - once the patches are applied,
and "finished", the patches go away,  but since they are VC
ed, you can always timetravel back to prior "versions" of the patches and do
all the dvcs things w/o too much hassles - and WITHOUT any false conflicts
when doing a fresh pull.

I've kept multiple, parallel sets of "local commits" on top of the
hg-subversion bridge, jumping back and forth between "branches of patch
sets", all the while rebasing to tip of tree, one patch branchset at a time.

I believe git has a similar system for maintaining "branches of patches"

Seriously folks, there are solutions to these problems - we don't have to
burn down the world for the sake of dvcs "purity"

my 2c, obviously.

-jason



> In other words, svn is not a distributed SCM.  It has long struck me as
> odd that a project whose license encourages private copies would stick
> with an SCM that has no support for keeping such copies.
>
> You may not care, but don't claim the current model is not broken.
>
>


> > The things I've heard against SVN appear to be relatively minor
> > inconveniences.
>
> I assure you, they are not.
>
> > And we do have a git repo for those who wish to use the newest, most
> > fangled thing. :-)
>
> No, we don't.  We have a git-svn mirror which is crippled compared to
> native git.
>
>                             -Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110909/f8be0999/attachment.html>