[svk-devel] SVK Lock? System global .svk?

[Jared Hardy]

So I have been using SVK for a couple of weeks now, with my old
Subversion project as a mirror repository, and I love it. I just have
to "add" a few features before I can start deploying the SVK client
and related internal GUIs to the rest of the office. I'm wondering
whether I should just hack our internal copy and distribute the hacked
version, write external wrapper scripts to avoid changing SVK, or
submit patches to get these features in the main line?

I. SVK Lock
    We actually have been using Subversion to version a lot of large
binary files -- images, 3D models, and other proprietary binary
formats. We don't have merge tools for most of these file types, so we
can't allow concurrent edit. I haven't seen an equivalent to "svn
lock" in SVK, so I'm wondering who would mind if I added that feature?
    In particular, since we are really just using the SVK mirror
feature to act as an alternative WC cache to svn for a central
Subversion repository, all SVK Lock related commands on a WC would
automagically get passed through to the mirror source, and the mirror
source would pass back errors and lock status through the SVK client.
    In our internal use case, any local branch copies of a mirrored
branch will probably be used for "changeset" management -- a managed
group of changes that are intended to be committed to the mirror
source as an atomic lump, separate from other changes taking place
locally. Therefore, we desire Locks on any file in such a branch to be
reflected in the mirror source repo. I am wondering -- is this use
case common enough to try to make it an SVK configuration option?
Otherwise, I will just handle these "changeset" branches through
external wrapper scripts.

II. System global .svk cache folder
    I already made one hack locally, to have svk (the perl script
file) look for the default .svk cache folder in ${SVKPATH} instead of
${HOME}. I am defining ${SVKPATH} as a system variable, so that we can
use a per-machine ".svk" cache, instead of a per-user cache. If I
submitted a patch to allow the option to choose between a per-user or
per-PC ".svk" default path, what would be the best method to have the
user define their choice? Should I have something like "if ${SVKPATH}
exists ${HOME} = ${SVKPATH}, else ${HOME} = ${HOMEPATH}"? Or should I
parse some config file entry?

    I haven't even started on the SVK Lock code, so any tips on how to
proceed would be appreciated. I imagine I will copy a lot of code from
some similar command, like "svk propedit ...", and handle error
conditions returned from the mirror source server. Should I make the
"--force" option the only way to steal the lock, or prompt the user
with a "(s)teal lock" option on any failure? Also, would anyone object
to automatically stealing the lock if the current lock owner name is
the same as the requester user name? I assume svN doesn't do this by
default because the user might have the lock on a different WC on
another PC, and may need a reminder.

    One noob question: what is the best way to apply properties to new
files automatically (without scripting "svk propset ..." into all "svk
add ..." operations) based on filename, extension, or other path
pattern matching? I didn't see anything similar to svN autoprops in
the SVK documentation. I would want to use this feature extensively
with the "svn:needs-lock" property, as well as "svn:ignore" and
"svn:eol-style".

Thanks!
Jared