inline On Fri, Nov 5, 2010 at 10:43 AM, Frans Bouma <[email protected]> wrote:
> > A move to git has been suggested multiple times with a majority being for > > it. > > > > I am very puzzled how you can be happy with svn. The performance of > > switching and managing branches/patches is so much quicker and faster. > > over a remote line? Sure. Locally, not so sure the difference is > that big. > > Most of us *work* with remote repos pretty much all the time > > I must be doing something wrong I get tree conflicts all the time when > > merging / doing svn update after directory renames. If you have a lot of > > uncommitted changes merged together with svn update conflicts it can be a > > mess to sort out (some times). > > The biggest mistake people make with SVN is that they manage their > repository on disk. Moving a file in a folder on disk and then execute > commit will not move the file in the repository. It will delete the file > and > add 'some file with the same name' elsewhere. So do folder management and > file placement in the repository, then do an update. Changing a file simply > requires a commit. > > Huh? Why do I need to pander to my SCM? > Sourcecontrol is all about scheduling work properly. In a way it's > the same as concurrency control on a database: if you schedule the work > properly, the friction is non-existent. So if you edit the same code in two > repositories, one a branch of the other, and then try to merge changes on > old in new, you'll get merge conflicts. This is logical and also not > avoidable in git. If you have lots of changes in old and new, first commit > new, then merge old. > > With Git, it will usually not require manual intervention. . The main reason is that if you do > things right with central trunk, there are not that many problems, same is > true with decentralized trunk. > In C/C++, avoiding memory leak is simple, just free your allocated memory. Doesn't work there either.
