Grant Baillie wrote:
On 10 Sep, 2007, at 15:33, Reid Ellis wrote:
Hear, hear. I would especially like to hear more about how Grant works
with svk. Or perhaps I should just search back in the mail archives
for when he talked about it before.
I think what you'll find is a link to the wiki page where I wrote it all
up:
<http://chandlerproject.org/Journal/GrantBaillieSvkNotes>
Grant,
Can you either share or replicate a svk depot across multiple machines?
I currently use Mercurial to do my local work, but mainly for the
ability to replicate changes across all my development machines (7 of
them) without needing to involve the upstream repository until I am
finished with the new feature. Mercurial can also be used as you are
using svk, tracking all changes in a tighter integration with the
upstream repository, but I didn't feel like I needed that so didn't go
that far. In a nutshell my workflow is something like this:
* I have a single workspace on a single machine where I check out a
working copy of a specific branch from the upstream version control
(svn, cvs, whatever) and I also store all of this working copy in a
Mercurial repository. (Except for the .svn dirs, as they tend to
contain empty directories and Mercurial doesn't deal with those very
well yet.)
* This repository is then pushed/pulled out to other working copies on
other machines as needed.
* When I'm working on a new change I do my initial work on one platform,
which platform depends on the nature of the change, but doesn't matter
as far as Mercurial is concerned. When I'm ready to try it out on the
others I check-in the change to the local Mercurial repository.
* I then switch to the other platforms and pull the change(s) into their
local repositories, and test, tweak, etc. as needed, committing any
additional changes that were needed on that platform.
* I repeat this until the change is fully functional and fully tested on
all platforms, and then I make sure that all changes are pushed to the
original repository that is also the upstream repository working copy.
I then commit the change to the main svn or cvs or whatever.
* When I update from upstream I just do a normal svn update command,
check-in the changes to the local Mercurial repository, and then
push/pull those changes as needed to all the other repositories so they
are all synced with the upstream repository.
This approach doesn't maintain all of my little per-platform
micro-changes as distinct change sets in the upstream repository, but
most of the time I wouldn't want it to anyway. I just want the
end-result to be tracked as a single change there, and so this method
works very well for me.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
