| 1 | ||
|
Editor: Beuc
Time: 2007/07/01 13:48:06 GMT+0 |
||
| Note: revert | ||
changed: - 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. Help 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 Then you can have a look at http://svk.elixus.org/ and http://svkbook.elixus.org/ , which are pretty sparse as of 2006-04-08. Initialization Init commands:: # 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 '.svk' 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 See also http://svk.bestpractical.com/view/SVKBootStrap Working copy Initial checkout:: cd /usr/src svk co //local/savane/trunk savane Update To merge:: 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 - 'experimental' and 'Savannah-specific'. 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 ('svk push'). Yet another insecure one would be to --relocate '//mirror/savane' to 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 'svk pull'. 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
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
Then you can have a look at http://svk.elixus.org/ and http://svkbook.elixus.org/ , which are pretty sparse as of 2006-04-08.
Init commands:
# 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 .svk 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
See also http://svk.bestpractical.com/view/SVKBootStrap
Initial checkout:
cd /usr/src svk co //local/savane/trunk savane
To merge:
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).
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 ...
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 - experimental and Savannah-specific.
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 (svk push).
Yet another insecure one would be to --relocate //mirror/savane to 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 svk pull. Maybe it adds some revprops for this? If not, I think we're KO.
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