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
|