Bill Wendling <wendling at apple.com> writes:>> 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. >> > It's my understanding that the upcoming new version of SVN will have > off-line commits available.Frankly, that's the least important feature git has.> And syncing will always be a problem if your tree has greatly diverged > from the main trunk. No code management system will alleviate that.Not true. SCM support means you get to use all sorts of nice merge tools to handle the sync. Applying patches sucks.>> You may not care, but don't claim the current model is not broken. >> > If you think git will help you with this, you use the git mirror (or > create your own) and sync SVN to it. :-)As several people have stated before, this is only a partial solution. It leads to lots of false conflicts that must be resolved.>>> The things I've heard against SVN appear to be relatively minor >>> inconveniences. >> >> I assure you, they are not. >> > Just for the record, I've been using SVN for LLVM development for many > years now.Haven't we all?> I've used it for our own, rather complex, internal use -- branching, > patching, tagging. And while it may not be perfect, it's certainly not > broken.You must have a much higher pain threshold than I do. :)>> No, we don't. We have a git-svn mirror which is crippled compared to >> native git. > > So basically you want to use git and it doesn't play nicely with svn, > and you're blaming svn.No, I'm pointing out that svn doesn't support everything that some people in the LLVM development community need to be able to do. -Dave
On Sep 8, 2011, at 9:13 PM, David A. Greene wrote:> Bill Wendling <wendling at apple.com> writes: > >>> 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. >>> >> It's my understanding that the upcoming new version of SVN will have >> off-line commits available. > > Frankly, that's the least important feature git has. >And yet it's the first one that people point out. :-)>> And syncing will always be a problem if your tree has greatly diverged >> from the main trunk. No code management system will alleviate that. > > Not true. SCM support means you get to use all sorts of nice merge > tools to handle the sync. Applying patches sucks. >I use "svn merge -c <rev#> ..." with great efficacy. And it has a nice way to resolve conflicts.>>> You may not care, but don't claim the current model is not broken. >>> >> If you think git will help you with this, you use the git mirror (or >> create your own) and sync SVN to it. :-) > > As several people have stated before, this is only a partial solution. > It leads to lots of false conflicts that must be resolved. > >>>> The things I've heard against SVN appear to be relatively minor >>>> inconveniences. >>> >>> I assure you, they are not. >>> >> Just for the record, I've been using SVN for LLVM development for many >> years now. > > Haven't we all? >Not all, no.>> I've used it for our own, rather complex, internal use -- branching, >> patching, tagging. And while it may not be perfect, it's certainly not >> broken. > > You must have a much higher pain threshold than I do. :) >More than likely. But it hasn't been a huge problem for me to keep all of these in sync.>>> No, we don't. We have a git-svn mirror which is crippled compared to >>> native git. >> >> So basically you want to use git and it doesn't play nicely with svn, >> and you're blaming svn. > > No, I'm pointing out that svn doesn't support everything that some > people in the LLVM development community need to be able to do. >The LLVM development style is to do as much on ToT as possible with little branching or mirroring needed. This seems to be at odds with your development style, which is that you keep a tree of your own with your changes there. So there is then conflict. I doubt that things are going to change any time soon. -bw
Bill Wendling <wendling at apple.com> writes:>>> It's my understanding that the upcoming new version of SVN will have >>> off-line commits available. >> >> Frankly, that's the least important feature git has. >> > And yet it's the first one that people point out. :-)It is? I think you may be confusing offline operation with private branches. They are not the same. Some quick searching reveals that one or two SVN developers may be considering developing a distributed SVN. That would indeed be welcome and would alleviate a lot of issues. Unfortunately I can't find anything offficialish that indicates the idea is being persued. It also looks to be two years away, at least, given some rather hand-wavey predictions of when stuff could happen, if approved. Admittedly, this was a very quick search. If you have pointers, that would be very helpful.>> Not true. SCM support means you get to use all sorts of nice merge >> tools to handle the sync. Applying patches sucks. >> > I use "svn merge -c <rev#> ..." with great efficacy. And it has a nice > way to resolve conflicts.You use svn merge -c in a working directory merging from one branch to another. Don't confuse an SVN working directory or an SVN branch with a repository.> The LLVM development style is to do as much on ToT as possible with > little branching or mirroring needed. This seems to be at odds with > your development style, which is that you keep a tree of your own with > your changes there.It's not "my" development style. Plenty of places do exactly this. How else can an organization keep sane control over its source?> So there is then conflict. I doubt that things are going to change any > time soon.Too bad. -Dave