You're not currently signed in.
  • How can I set multi-line properties like svn:ignore?

Subversion uses "-F" to set properties from a file. Since SVK uses this option for something else, some other work-around is required.

If you are using SVK 2.0.0 or later, use the "ignore" command: 

svk ignore _build

For older versions of SVK, if your command shell is bash, then you can use a form of quoting to interpolate carriage returns into the command line: 

svk propset svn:ignore $'Makefile\nBuild\nblib\n' //local//project-A

Other shells may have similar quoting options.

  • Is it possible to mirror two remote repositories to each other say :

Repository ONE in Paris, repository TWO in London and be able to create 2 mirrors then smerge both, doing it on a node in Berlin and using the mirror function?

Sure. Simply do this: 

svk mirror svn://svn.paris.fr/ //paris

svk mirror svn://svn.london.uk/ //london

# pick a sensible base, or use --baseless

svk smerge --base=1234 //paris //london

# ... and smerge between them normally ...

svk smerge -I //london //paris

svk smerge -I //paris //london

/Q: Does the above mean that on "svn.paris.fr" and "svn.london.uk", the regular Subversion "svnserve" server should be running on top of the SVK repository?

A: You can use any repository access method and works as with svn.

For svn:// you need svnserve in the remotes side(s).

/

See also SVKGlossary.

  • Given an svk repository, do you have to use it via svk, or can you use svn programs to access it?

Short answer: svn programs that only read the repository are working fine;

those who actually write in the repository would bypass svk and make it fail (when writing to mirrored repositories, local braches should be ok. See UsingSVKAsARepositoryMirroringSystem).

svk doesn't have its own repository format. when you use svk depotmap you actually map svn repositories to names that svk could access. So yes, it is always accessible from svn programs. See also SVKForSubversion for what svk could do for you if you want to stick with the svn command line client.

(Note that whatever client you are using you will need a version built against svn1.1 or later to recognise the fsfs repository that svk makes, typically under the ".svk\local" in your HOME directory. The working copy format is different, but that does not preclude you from checking out a working copy with svn, from the same local repository as svk uses. -- AutrijusTang)

The short answer to the spirit of this question appears to be no. Subversion clients (such as TortoiseSVN or RapidSVN) do recognise the svk repository as a svn repository and will allow you to browse, checkout, add, checkin etc. But checking in with such clients bypasses the additional work that svk checkin would do if you checked in from a svk working copy -- ie. creating merge tickets or whatever -- so that svk smerge does not work, giving a friendly error in SVKWin32 like: 

F:\GeneSys\SVKGlenn>svk smerge -C //Genesys/GlennBranch //Genesys/GlennSVKTest

Filesystem has no item: File not found: revision 84, path '/Genesys/GlennSVKTest' at

D:\DOCUME~1\JOEYJI~1\LOCALS~1\Temp\par-Joey_Jimbob\cache-ef9a813f4fce2ea0301f58a4050

44d93822ea5e9/inc/lib/SVK/Target.pm line 103

(I look forward to being corrected about this if I am wrong, or if there is a work-around for this. Even if one could use svk commit in a normal svn working copy (of the kind checked out by svn clients). Even a list of what will work and what will not would be helpful. -- GlennBurgess)

(Thanks for the feedback; the short answer is: Committing anything to mirrored paths with svn will surely lead to breakage; merging with "svn merge" will cause subsequent "svk smerge" to lost merge history, resulting in possibly duplicated merges; all other operations should be safe. --AutrijusTang)

  • Is there a forum for SVK, or is this the preferred mode of communication?

The Mailing list, or on IRC: irc.freenode.net #svk channel.

  • *What version of Subversion must be installed to use SVKWin32?*

Building SVKWin32 needs Subversion 1.1rc2 or later versions, with swig/perl bindings. Running the binary distribution does not require a preinstalled Subversion.

  • Does svk allow you to make several commits to your local copy of the repository and then be able to merge all the commits back to the main repository (keeping all the log messages)?

Yes - this was its very first feature. However the merge of local changes will be one commit in the remote repository by default, unless you use smerge -I. Meanwhile, smerge -l will bring the logs to the commit made to remote repository.

  • Does svk allow you to push changes back to a server without having write access to the server (eg., a non-core-developer contributes a patch, including a log message, which a core developer reviews before applying the patch)? Similarly, can multiple local repositories share patches without going through a central server?

It's planned to support such daemon collecting patches. see SVKStatus. For supporting peer repositories, as long as the local repository is exported with svnserve or http, the smerge command already knows how to handle changes between multiple related repositories.

  • Can I rename the directory that contains my working copy after I checkout?

For CVS and SVN, there are CVS and .svn directories there to keep track of it's Repo. But svk doesn't work that way - so don't do that now!

If you insist, you can hand-edit your $HOME/.svk/config file to point the checkout copies elsewhere, but please be cautious doing that, and make a backup of the config file before you run "svk" again.

A "--relocate" option in svk has been planned.

Update: (20 July 2007), this has been implemented as svk checkout --relocate DEPOTPATH_ORIG|PATH_ORIG PATH_DEST (tested with SVK 1.08)

svk checkout --list gives the list of checkout copies (i.e. the map from depotpaths to paths of checked out copies)

svk checkout --relocate acts on one item of that list, changing the checkout path (see svk help co for reference).

  • How do I list all mirrored repositories in my depot?

svk mirror --list works since 0.18 release. For earlier version, use svk pl -v // to get some hints about path mirrored.

  • Why does svk sync keeps asking me about password when I use svn+ssh://?

This is in the Subversion FAQ. In short, some operations invoke multiple RA sessions, which means multiple ssh invocation with svn+ssh://. You should use ssh-agent to avoid such inconvenience.

  • How do I configure svk to use proxy thru http(s)://?

Currently svk doesn't have its own configuration file. however it loads the one that subversion uses, which should be ~/.subversion/servers. It will be created after the first time you run svn.

  • Why doesn't svk prompt for password when committing to http(s):// mirrored source?

This feature has been implemented in SVK 0.21, please upgrade.

  • I just built svn1.1, how can I convert current bdb repository, into using fsfs ?

Basically, you create a fsfs repository first, and then proceed a dump/load. So it's like: 

cd ~/.svk/

svnadmin create --fs-type=fsfs local.fsfs

svnadmin dump -q local | svnadmin load local.fsfs

# (Go to do laundry)

mv local local.bdb

mv local.fsfs local

After I (gugod) do that, I found: 

[~/.svk] du -sh local local.bdb 

228M    local

524M    local.bdb

How nice!

If you are loading into a non-empty repository, please use 'svnadmin load --force-uuid' so the original uuid is kept.

  • I was running svk sync to mirror a repository, and it encountered an error in the middle of the process. How can I resume where it left off?

Normally, "svk sync" should be able to pick up where it left off. However, there is a slight chance that a sync may be terminated at the middle, leaving the mirrored path in an inconsistent state. As of svk 0.23, this will fix it: 

svk mirror --recover //Project

svk sync //Project

Specifically, when you run svk mirror --recover it will find the last committed revision and ask you to confirm that is the correct revision. When you answer with a 'y', it fixes the repository so that you can then resume the sync. graco strollers

  • I install debian package svk with version 0.26 but svk --version tell me it's 0.25.

Try to remove the SVK.pm and dir "SVK" in /usr/local/share/perl/5.8.x/.

  • "svk sync --skipto HEAD" sometime make repo much bigger than "svk sync"

If you mirror svn repo, and that svn repo has experienced many "svn cp", then --skipto HEAD will use more space.

  • When I use svk under Win32 system, "svk depotmap --init" failed, got messages like "無法於「%USERPROFILE%\.svk」建立 SVK 的設定目錄：No such file or directory at...."

Try to "set SVKROOT=C:\" under Win32 Command line

  • What's this SVK PATCH BLOCK in the patches?

It's like a floating/uncommitted branch, so when doing svk patch apply, it does not only do context patch like /usr/bin/patch, but does real 3 way merge as it knows the base.

  • *Can I use TortoiseSVN with the repositories svk mirrored?*

Yes, but you need to be careful not to commit to the mirrored path directly. Create a local branch and then you can use TSVN for committing there, and use svk to push and pull.

We are also working on a commit hook that disallows such dangerous commit by other svn clients to the mirrored path.

  • Can multiple admins keep /etc under revision control sanely?

With some care, yes. The initial import is easy, with something like: 

cd /etc && svk import --to-checkout //system/etc

Thereafter, /etc is considered a checked out tree and you can interact with as you would any regular working copy.

There are three issues here. First, you need to be careful about permissions and ownership. Second, it's best if all the admins use the same depot. Finally, it's nice to see which admins committed which changes in revision history.

When you commit new and modified files, svk won't interfere with permissions and ownership. But any action that updates the checked out tree from the depot will. This includes the revert and update commands. Your admins need to understand this and verify permissions and ownership when using these commands.

If all the admins log in as root, they'll have to agree to use a custom svk wrapper that insists on being given a username (as a command-line or environment variable) to use for the revision history, which the wrapper would place in the USER environment variable.

If the admins log in as unprivileged users and then use either sudo or ksu to become root and perform edits and commits, they don't need to remember to use a wrapper.

Heimdal Kerberos' ksu leaves the USER environment variable alone, but updates HOME. This is perfect, because it means revision history will get the unprivileged username, but svk will use /root/.svk as the depot.

The sudo package can be made to behave the same way with the following in /etc/sudoers: 

Defaults>root   always_set_home, !set_logname