 |
 |
On Jan 22, 2009, at 11:41 PM, Peter W. Draper wrote: > > I think these are the key arguments for me. Having to hold off on > commits > until "it's ready" always makes me uneasy, it also has the side- > effect of > discouraging atomic commits, so a changeset is generally not very > helpful > to look at when you forget quite why or when some change was made, > it's > hidden amongst a batch of others. > > This point may be more important for me as I work with other > people's code > a lot, so understanding the changes is important. > > Basically I see this as moving back to the old days when I had my own Was expecting a "good" to be inserted there somewhere:-) > One thing that worries me about a switch is how secure the local > repositories are. Clearly these need backing up, so I need to work > out how > to keep the bare repositories on backed-up filesystems. There's also > the > issue of thirdparty/vendor branches, where are those kept. Well, in that regard David has as much chance of losing all his work from a disk crash now as we would from a disk crash when using a DVCS. Although he could set up a cron job to rsync the entire repository to JAC or somewhere. Having disk crashes in the middle of developing is always going to be an issue. Vendor branches are interesting in that they work fine but you have to make sure that they end up on the master repository just like releases. See http://happygiraffe.net/blog/2008/02/07/vendor-branches-in-git/ http://sourceware.org/frysk/build/git-fu.html so you keep your patches on a branch and can merge them in each time you get an updated version of the code. And because the thirdparty directories do not have .svn directories or anything you can simply remove the old tree, untar the new one and the DVCS will know which files were removed, which renamed, which added and you can just commit it all in one go. Then pull in your upstream local modifications and finally merge it all to trunk. if the vendor happens to be using a git repository you can actually add them as a submodule and track a particular release directly.... http://woss.name/2008/04/11/using-git-submodules-to-track-vendorrails-2/ http://woss.name/2008/04/09/using-git-submodules-to-track-vendorrails/ -- Tim Jenness Joint Astronomy Centre