On May 12, 2008, at 14:26, Ilyes Gouta wrote:
> Hi!
>
> I have a special use-case that I would like to have your opinion on
> and if it's doable or not using Subversion. So, here it is:
>
> I'd like to "clone" a public SVN repository and make the new
> repository accessible to my team. Each member of my team will have his
> working copy checked-out from the "cloned" repository, which is
> internal, and will check-in its code to it. I'd like also to
> periodically synchronize that repository with the public one to
> reflect the latest public changes. So, the "cloned" repository will
> act as a repo. as seen by my team members and as a "working-copy"
> from the public repository point of view.
>
> Is this doable using SVN?
>
You might take a look at the tools and presentations available here: http://www.clifford.at/
Clifford Wolf has had considerable success using his svnemboss, and
svnbranch scripts to track vendor branches and manage patch stacks (as
branches) on top of those vendor branches.
hmm... I just hopped off to clifford's web page to get you the direct
link to his presentation, when I noticed that it was in German.
Oops. I just heard it recently but I often forget what language I
heard things in after the fact. I took some notes (in English) during
the presentation. Perhaps you'll find them of some use:
#title Notes form "Advanced Subversion" given by Clifford Wolf in
Vienna on 2008-04-24
** svnbranch
Shell script to automate branching, tagging and merging.
http://svn.clifford.at/tools/trunk/svnbranch.sh
Keeps track of parent (source) of branch. Both URL (location) and
revision Propagate command to automatically merge changes from parent
to children.
Displays branch, tags, merges graphically. (as a .dot file).
*** svnbranch branch
Does the copy, sets the svnbranch:parent and deletes any svnbranch:tag
property.
*** svnbranch tag
Same as branch, except for setting svnbranch:tag property which
prevents other svnbranch commands (sync and propagate) from altering
its contents.
*** svnbranchs sync
Merge changes from parent into working copy. updates revision on
parent property. changes commit-ready in working copy.
*** svnbranch sync URL
re-parents the branch in the current working copy. merges in changes
between old and new parent. (sounds a little like git rebase).
*** svnbranch propagate
started in working copy of parent. creates a shell-script
propagate.sh. this performs recursive synchornization of all children
of the parent. (holy-meta-programming batman!) ;-) and it's
self-modifying to keep track of where it left off in case it's forced
to stop for a merge conflict. huzzah!
*** svnbranch merge URL
Started in parent. Changes in branch (URL) relative to parent merged
into working copy. The changes to be merged are the changes between
branch head and last sync revision.
This is used when it's time to reintegrate a branch back into its
parent, generally making the branch obsolete.
It sounds to me like svnbranch would be a great tool for managing
feature branches. With sync we can keep up with changes in our
parent so that we don't build up a huge merge conflict while we work
in isolation. With svnbranch merge we then move our changes back to
trunk when they are 'done done'.
*** svnbranch diff
"incoming" changes from parent.
*** svnbranch show
Shows a graphical view of branch history. Three variants.
- list: ascii
- graph: .dot
- show: shows postscript of .dot using kghostview; edit script if you
want something different.
*** svnbranch:index
Property on root of repository which stores an index of the branches
in the repository.
e.g
tags/*
branches/*
This needs to be set by hand before you use svnbranch for the first
time.
* Vendor Trees
To maintain local changes on external sources on which we depend and
from which we want to track future changes.
The canonical version from the vendor (unmodified):
/vendor/foolib/1.0.
Make a local branch of this to: =/trunk/foolib=. Make your local changes
there.
When the new foolib comes out: =/vendor/foolib/1.1=
Then, what you'd like to do is merge the changes between 1.0 and 1.1
to trunk. Before you can do this, however, you have to get 1.0 into
the ancestry of 1.1. Without this SVN will see the difference as "a
whole bunch of deletes" followed by "a whole bunch of adds". No good.
** svnemboss
=svnemboss master-path wc-path=
Makes the changes to wc-path that are necessary to make wc-path
identical with master-path.
svnemboss doesn't try to be smart about renames. uses rsync to do the
actual work. It then does a status and just adds all the =?= entries
and removes all the =!= entries.
I don't know how many times I've done exactly this *by* *hand*. I
don't
know why *I* didn't think to write a script to automate it before
now.
See also =svn-load-dirs.pl=, which fulfills a similar purpose but works
very differently.
** Patch stacks
Maintain a series of separate patch sets as a chain of branches, on
each of these branches maintain one patch set. By changing svnbranch
parent property we can remove a link form this chain in order to
remove a patch set from consideration.
+--------------------+ +-------------------+
| /vendor/kernel-1.0 | | vendor/kernel-1.1 |
+--------------------+ +-------------------+
^ (parent)
| +---------------+
+--| Bug fix patch |
+---------------+
^ (parent)
| +--------------------+
+--| some feature patch |
+--------------------+
With =svnbranch sync URL= you can reparent (I think *git* calls this
"rebase") the branch "Bug fix patch" to kernel 1.1. By propagating
the changes down your branch chain you can move your entire patch
stack from kernel 1.0 to 1.1. Pretty slick.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-13 19:59:14 CEST