[Chandler-dev] How we develop post Preview : SVN topology

[Grant Baillie]

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