[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: A special use-case using subversion

From: Benjamin Smith-Mannschott <bsmith.occs_at_gmail.com>
Date: Tue, 13 May 2008 19:58:41 +0200

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.


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

*** 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.



This needs to be set by hand before you use svnbranch for the first

* 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):

Make a local branch of this to: =/trunk/foolib=. Make your local changes

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
   know why *I* didn't think to write a script to automate it before

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.