[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: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 14 May 2008 19:38:13 +0200

On Wed, May 14, 2008 at 12:23:28PM -0400, Andy Levy wrote:
> On Wed, May 14, 2008 at 5:55 AM, Ilyes Gouta <ilyes.gouta_at_gmail.com> wrote:
> > Hi,
> >
> >> Why would you need to create a new branch for every sync?
> >
> > This is how it's explained in the vendor branches paragraph, in the
> > SVN book. As far as I know, we can't update a branch with the
> > revisions coming from another SVN repository. We can import it as a
> > new code, in a new branch, (and then merge it back in the said
> > long-living branch?). Am I right?
>
> You could also use svn_load_dirs.pl to "import" the latest version,
> with all the adds/deletes/updates since the previous version.

Exactly, with this you only create the vendor branch once.

Ilyes, the basic idea is this:
When updating to a new version of the vendor's code, you check
out the vendor branch, which contains a previous version of the
vendor's code, into a working copy. Then you make that working
copy match the new version of the vendor's code -- this is the part
that should be automated better than it currently is.
Then you commit from the updated working copy to the vendor branch.
Now the vendor branch carries the new upstream version, and you can
merge from it into your own branches (and trunk).

So no, you really don't recreate the vendor branch every time you
do a sync to the vendor's most recent code. You just checkout the
vendor branch, make that working copy match the new version,
and then you commit.

To automate the updating process, we currently only have svn_load_dirs.pl,
piston (http://piston.rubyforge.org/) and similar wrapper solutions.
But they all use the same basic idea explained above.

Stefan

  • application/pgp-signature attachment: stored
Received on 2008-05-14 19:37:07 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.