<br><br><div class="gmail_quote">On Thu, Sep 8, 2011 at 5:09 PM, David A. Greene <span dir="ltr"><<a href="mailto:dag@cray.com">dag@cray.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Bill Wendling <<a href="mailto:wendling@apple.com">wendling@apple.com</a>> writes:<br>
<br>
</div><div class="im">>> Let's face it, Joe Dragon is pretty much happy with svn and there's an<br>
>> svn-git bridge for the rest of us.<br>
<br>
</div>The svn-git bridge is broken as several people stated before. It is<br>
easier to contribute code via the gateway but it causes headaches when<br>
one updates one's working git clone after submitting through dcommit.<br>
The git pull generates all kinds of false conflicts. This is because<br>
svn doesn't understand git history and never will.<br>
<br>
git-svn will never be a replacement for git.<br>
<div class="im"><br>
> For me, the question is "why do we *need* to switch our versioning<br>
> system?". Nothing is broken with our current model.<br>
<br>
</div>There are things broken with the current model, though you may not care<br>
about them. It is not possible to conveniently keep a private copy of<br>
LLVM and associated projects and sync regularly with upstream. It flat<br>
out sucks. This is because the svn model is fundamentally opposed to<br>
the idea of private repositories. There's One True Repository and<br>
that's it.<br>
<br></blockquote><div><br></div><div><div><br class="Apple-interchange-newline">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</div>
<div>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.</div><div><br></div><div>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.</div>
</div><div><br></div><div>I believe git has a similar system for maintaining "branches of patches" </div><div><br></div><div>Seriously folks, there are solutions to these problems - we don't have to burn down the world for the sake of dvcs "purity"</div>
<div><br></div><div>my 2c, obviously.</div><div><br></div><div>-jason</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
In other words, svn is not a distributed SCM. It has long struck me as<br>
odd that a project whose license encourages private copies would stick<br>
with an SCM that has no support for keeping such copies.<br>
<br>
You may not care, but don't claim the current model is not broken.<br>
<div class="im"><br></div></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> The things I've heard against SVN appear to be relatively minor<br>
> inconveniences.<br>
<br>
</div>I assure you, they are not.<br>
<div class="im"><br>
> And we do have a git repo for those who wish to use the newest, most<br>
> fangled thing. :-)<br>
<br>
</div>No, we don't. We have a git-svn mirror which is crippled compared to<br>
native git.<br>
<br>
-Dave<br>
<div class="HOEnZb"><div></div><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br>