[svk-devel] [Noob Alert] Subversion => SVK
Mark Lundquist
mlundquist2 at comcast.net
Fri Jan 19 16:37:57 EST 2007
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—
More information about the svk-devel
mailing list