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

[Mark Lundquist]

OK, now that I have svk running... :-)

I'm veteran subversion user, I understand about global rev space, 
branch/merge etc., how to administer repos, etc.  Are there any good 
articles around on "switching to svk, for experienced svn users"?

Mainly, I want to know about major differences btwn. working in svk vs. 
svn, e.g.:

	• Any "gotchas", i.e., "you did it this way in svn, but if you try 
that in svn you will really scr*w yourself"

	• Anything along the lines of "you did it this way in svn, and while 
that will still work in svk, you really
	  don't want to, because this new way X is so much better."

	• Some explanation of the "new" (to an svn user) commands; why are 
they there, what to they do for you?

Other questions:

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?

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

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?

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?

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?

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)?

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?

That's all I can think of right now :-)

cheers,
—ml—