On 15 Nov 2012, at 12:31, <dag at cray.com> wrote:> - Easier third-party merging. Merging via git merge/rebase is MUCH > simpler than merging a tarball from svn. I know the llvm leaders > don't seem to care about this but it is a real issue for many users. > > - Ease of fork/merge. git makes it easy to experiment with long-lived > development branches. svn forces all development into trunk which > limits experimentation and innovation.Neither of these are true. There is nothing stopping people from working in branches in svn and merging from branches is easy. The advantage with git is that it's very easy to have your fork somewhere where no one else sees it and your changes get lost and forgotten. Your point about small incremental commits is also untrue. svn encourages small incremental commits and, more importantly, encourages small incremental pushes upstream. This is something we want to encourage: we don't want to make it easier for people to have private forks than it is to push them upstream. David
David Chisnall <David.Chisnall at cl.cam.ac.uk> writes:> On 15 Nov 2012, at 12:31, <dag at cray.com> wrote: > >> - Easier third-party merging. Merging via git merge/rebase is MUCH >> simpler than merging a tarball from svn. I know the llvm leaders >> don't seem to care about this but it is a real issue for many users. >> >> - Ease of fork/merge. git makes it easy to experiment with long-lived >> development branches. svn forces all development into trunk which >> limits experimentation and innovation. > > Neither of these are true. There is nothing stopping people from > working in branches in svnYes there is. I have asked about it many times and have always been refused.> and merging from branches is easy.That is absolutely not true for any significant merge operation.> The advantage with git is that it's very easy to have your fork > somewhere where no one else sees it and your changes get lost and > forgotten.Actually that's true today with svn. We have a ton of changes here we'd like to submit but the process is really painful.> Your point about small incremental commits is also untrue. svn > encourages small incremental commits and, more importantly, encourages > small incremental pushes upstream.An svn commit is an expensive operation. A git commit is a cheap operation. That's why I'm referring to. Development inertia under svn tends to steer the developer toward making larger changes before committing. With git committing becomes an almost unnoticed part of the process. At least that's been my experience.> This is something we want to encourage: we don't want to make it > easier for people to have private forks than it is to push them > upstream.There is value in those private forks. As I said, having places to experiment is important. -David
The thing about this is that git-svn (un?)fortunately works so well that you can get all of these benefits with the main repo still in SVN. Hence, it is really a moot point regarding a switch to git for the main repo. E.g.:> Actually that's true today with svn. We have a ton of changes here we'd > like to submit but the process is really painful.Is there any difference from the standpoint of how "painful" it would be to merge back between: 1. pure-git workflow: your development is on a branch that you then need to integrate upstream. 2. use the git mirror with git-svn: your development is on a branch that you then need to integrate back into mainline. Both seem to be basically the same. I agree that if you aren't developing with git for the local branch, then it would be insanely painful, but the fact that git-svn allows for git on the local side gives all of the benefits in this particular case without having to move the main repo away from SVN. -- Sean Silva On Thu, Nov 15, 2012 at 6:59 PM, <dag at cray.com> wrote:> David Chisnall <David.Chisnall at cl.cam.ac.uk> writes: > >> On 15 Nov 2012, at 12:31, <dag at cray.com> wrote: >> >>> - Easier third-party merging. Merging via git merge/rebase is MUCH >>> simpler than merging a tarball from svn. I know the llvm leaders >>> don't seem to care about this but it is a real issue for many users. >>> >>> - Ease of fork/merge. git makes it easy to experiment with long-lived >>> development branches. svn forces all development into trunk which >>> limits experimentation and innovation. >> >> Neither of these are true. There is nothing stopping people from >> working in branches in svn > > Yes there is. I have asked about it many times and have always been > refused. > >> and merging from branches is easy. > > That is absolutely not true for any significant merge operation. > >> The advantage with git is that it's very easy to have your fork >> somewhere where no one else sees it and your changes get lost and >> forgotten. > > Actually that's true today with svn. We have a ton of changes here we'd > like to submit but the process is really painful. > >> Your point about small incremental commits is also untrue. svn >> encourages small incremental commits and, more importantly, encourages >> small incremental pushes upstream. > > An svn commit is an expensive operation. A git commit is a cheap > operation. That's why I'm referring to. Development inertia under svn > tends to steer the developer toward making larger changes before > committing. With git committing becomes an almost unnoticed part of the > process. At least that's been my experience. > >> This is something we want to encourage: we don't want to make it >> easier for people to have private forks than it is to push them >> upstream. > > There is value in those private forks. As I said, having places to > experiment is important. > > -David > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
16.11.2012, 01:06, "David Chisnall" <David.Chisnall at cl.cam.ac.uk>:> On 15 Nov 2012, at 12:31, <dag at cray.com> wrote: > >> - Easier third-party merging. Merging via git merge/rebase is MUCH >> simpler than merging a tarball from svn. I know the llvm leaders >> don't seem to care about this but it is a real issue for many users. >> >> - Ease of fork/merge. git makes it easy to experiment with long-lived >> development branches. svn forces all development into trunk which >> limits experimentation and innovation. > > Neither of these are true. There is nothing stopping people from working in branches in svn and merging from branches is easy. The advantage with git is that it's very easy to have your fork somewhere where no one else sees it and your changes get lost and forgotten. > > Your point about small incremental commits is also untrue. svn encourages small incremental commits and, more importantly, encourages small incremental pushes upstream. This is something we want to encourage: we don't want to make it easier for people to have private forks than it is to push them upstream. >With git it's very easy to do commits incrementally and then squash them into logically complete pieces. With SVN it's just impossible -- Regards, Konstantin