[As of August 2013 (and earlier): The Savane/Savannah differences have long since stopped being tracked. GNU Arch is not actively used for Savannah, and Subversion only started being used in the "administration" project a couple weeks ago, for the new ikiwiki-based. Never heard of svk. --karl]
[SVK is a distributed vcs "wrapper" around Subversion. It will work with any Subversion backend. I imagine the previous Savannah Hacker used SVK in the same way that I am using git-svn to interact with subversion backends now. I have used svk in the past but git-svn is better IMNHO. Since the time in the past discussed on this page Savannah has been migrated to git and so no distributed wrapper is needed since git is natively distributed. --rwp]
We needed to track a couple Savane changes specific to Savannah, such as the local configure.cache configuration, favicon.ico, keeping the FAQ around, plus the magic number anti-spam trick.
We did so by creating a local SVK branch and keep sync-ing with it.
Hopefully, any change tested at Savannah could be cherry-picked (in the GNU Arch sense of cherry-picking) directly back to the Gna! repository, easying later upgrade (read: avoid conflicts).
Here's how we did it in 2006. At the time I was globally dissatisfied because SVK is slow, I had troubles getting my branching done (but maybe my branching scheme wasn't clean), the lack of answer when submitting detailed bug reports to the mailing list, and the fact I irremediably messed my local SVK repository a couple times. This may have changed since then with SVK2. It's still nice to be able to remotely clone and use a SVN repository.
The appropriate documentation to read first is integrated in SVK. Don't look anywhere else until you read it - it'll save you time:
svk help intro | less
If you know GNU Arch, you should then have a look at this Arch/SVK comparison. Beware that annotations are a bit biaised toward SVK and only covers the basic, centralized commands:
svn co svn://svn.clkao.org/member/clkao/arch-tutorial/annotated/ svk-tut
# Define the local copy and its origin: svk mirror http://svn.gna.org/svn/savane //mirror/savane # Grab all the 5K revisions (long): svk sync //mirror/savane # Define the local branch svk cp -p //mirror/savane //local/savane # Check the result svk ls //
Alternative (with a wizard, select the default choice):
svk cp -p http://svn.gna.org/svn/savane //local/savane
The wizard offers to grab only the latest revision but warns that this
may lead to issues. When I tried it started creating a > 100M
while saying it grabbed only the latest revision log, so I killed it.
Hmmm, clkao says: "it's better to branch the project level, rather than toplevel for local uses". It's probably better to cp //mirror/savane/trunk //local/savane-trunk or something similar.
To save time and bandwith and load etc., you can download a SVN dump (\~180MB gzip'd), sync from it, and then relocate your mirror to the canonical URL:
wget http://svn.gna.org/daily/savane.dump.gz svnadmin create savane zcat savane.dump.gz | svnadmin load savane > out.txt # real 9m13.210s svk mirror //mirror/savane file://`pwd`/savane/ svk sync //mirror/savane > out2.txt # real 17m2.292s svk mirror --relocate //mirror/savane http://svn.gna.org/svn/savane svk sync //mirror/savane
cd /usr/src svk co //local/savane/trunk savane
cd /usr/src/savane svk pull
This should be the same than:
# Refresh our local copy svk sync //mirror/savane # Merge with the local branch svk smerge //mirror/savane //local/savane # Update the working copy cd /usr/src/savane svk update
smerge can probably be used in a more flexible way, for example
merging with a third repository (I mean: not the mirror mirror nor the
local copy, another branch).
Displaying the local changes
This one is the most accurate, it takes uncommited changes into account:
svk diff //mirror/savane/trunk .
This other one compares the two repositories, this is faster:
svk diff //mirror/savane/trunk //local/savane/trunk
Save a patch:
svk smerge -P patch_name ...
Publishing changes to Savane
I need to make the Savannah changes available to me (Beuc), so I can grab them at my personal machine and put them back at Gna!. I don't really know how to do so atm. In the worst case I'll make a diff.
I'd also like to perform some cherry-picking (e.g. only apply a
selection of revisions, not a complete merge - that way I can avoid
merging Savannah-specific changes yet still commit generic changes). But
generally speaking, cherry-picking is not very easy to manage (commit by
commit) - better create two distinct branches -
One solution is to publish the depot at Savannah (svn+ssh://root@sv?) so I can grab it at home.
Another one would be to setup a SVN server at home and have Savannah
commit there (
Yet another insecure one would be to --relocate
Beuc@svn.gna.org and commit from Savannah.
SVK probably needs to be used from end to end. I don't really know if
SVK will then understand that the Savannah changes I'll have committed
from home should not conflict with themselves at the next
Maybe it adds some revprops for this? If not, I think we're KO.
Setup a public branch
Overview: we create a separate branch that gets updates from 1) Savane@Gna and 2) changes from various SVN (direct) and SVK (offline) repositories.
To import updates from Savane@Gna:
svk mirror //mirror/administration svn://Beuc@svn.sv.gnu.org/administration svk sync //mirror/administration # let's try commiting only the trunk - no need to get a super-huge repository # with disconnected branches svk mkdir //mirror/administration/trunk svk smerge -B //mirror/savane/trunk //mirror/administration/trunk # initial connection svk push --from //mirror/savane/trunk //mirror/administration/trunk # or: svk smerge //mirror/savane/trunk //mirror/administration/trunk
On the developper machine:
svk mirror //mirror/administration svn+ssh://Beuc@svn.sv.gnu.org/administration svk cp -p //mirror/administration/... //local/administration/... svk co //local/administration/... # edit... svk push