On 11 Sep, 2007, at 10:13, Robin Dunn wrote:
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?
You can, but if you want to sync up changes you need a server (svn)
somewhere. You could serve up the SVK repository directly (since it
is actually a svn repository), but I believe that wouldn't work
correctly.
BTW, my understanding of Mercurial is that if you want "tight
integration with an upstream repository", that can't be a subversion
repository, right?
--Grant
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
