[svk-devel] [Noob Alert] Subversion => SVK

[Stig Brautaset]

On 20 Jan 2007, at 09:33, Mark Lundquist wrote:
> 1) The book has examples of  mirroring like
>
> 	svk mirror //mirror/whatev https://whatev/repo
>
> Is it sort of considered standard practice to create all your  
> mirrors in a subdirectory 'mirror' in the default depot like that?

Yeah, it's a convention. It's by all means not necessary, but some of  
us need all the mental help we can get to remember how things hang  
together ;)

> 2) If the remote repository moves out from under my mirror, how do  
> I follow it?

svk mi --relocate

> 3) I've read where people use svk to create their own private  
> branch of a remote repository for personal lines of development,  
> which they can then merge back to the mirror and then sync.  I  
> presume the way you do this is to "svk cp" from the mirror to  
> another location in your depot (but not within the mirror).  Is  
> that the right idea?

Yes, that's it exactly.


> 4) I work on some open source projects;  in particular, Apache  
> Cocoon which I use for many projects in my day-to-day work.  I  
> sometimes need to apply pre-GA Cocoon patches to my production  
> Cocoon builds.  Since this is a production development environment  
> I can't just have my builds be an uncontrolled patch-fest, so... I  
> devised a variation of the SVN "vendor branch" strategy to both  
> absorb new source releases while also maintaining my local mods  
> going forward.  Now, here's the catch: the Cocoon project maintains  
> its source in a publicly read-only SVN repository, and they tag  
> their releases.  So I think that with svk I can obsolete that whole  
> vendor branch strategy (it was really a pain, only less than the  
> total pain that would result if I did  not do it).  I can mirror  
> their whole repo, but maintain my changes locally (not in the  
> mirror), and then merge in the deltas between tags from the mirror  
> whenever they make a new release, right?

Yes, that should work.

> 5) Also, I'm not a committer on the Cocoon project (not yet  
> anyway), but I do try to contribute and make patches... and it  
> would be nice to be able to have someplace to commit to so that my  
> area doesn't devolve into a patchwork of checkouts.  Is there a way  
> to mark a mirror as read-only, so that when I commit to it it won't  
> try to sync back to the remote repo?

No, that's what local branches is for. At any time you can ask svk to  
produce a patch between your local branch and the mirror (i.e.  
upstream) (check out the -P flag to e.g. the commit and smerge  
command, and note that you can pass it '-' to print to stdout, then  
redirect this to a file)

> 6) Can I move the physical path of a depot to someplace else later  
> (e.g. I run out of space and need to move it to a new partition)?

Yes. Just update the depotmap accordingly.

> 7) Can I mirror a remote depot starting at its current HEAD instead  
> of back to the beginning of time?  Advantages / disadvantages to  
> doing this?

Yes you can; you can start mirroring a depot at any point in time. I  
seem to remember that this might use more disk space for branches/ 
tags, but I don't know this for certain.

Stig