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

Re: Help with Vendor branches/releases

From: Stefan Sperling <stsp_at_elego.de>
Date: 2007-11-26 16:25:51 CET

On Mon, Nov 26, 2007 at 02:39:13PM +0000, Nathan Watson-Haigh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> OK, I'll try to explain...
>
> Some time in the past, the project incorporated code (v1.2.12) from
> vendor1 into trunk/modules/modules1 and then made changes, before
> moving the code into an SVN repo. The SVN repo now doesn't have the
> history of the changes made to the 1.2.12 code from vendor1.
> Additional changes were made to the
> 1.2.12 code in the svn repo.

So you have no vendor branch at all yet, just code on trunk
based on 1.2.12, correct?
 
> I am now wanting to update the vendor code to v1.2.16. I am not able
> to obtain all the changes we made to the 1.2.12 code since some
> changes were lost in the CVS->SVN migration.

You can always obtain the changes by diffing your current code against
1.2.12 (e.g. with the plain old 'diff' command).

I would do this manually first before touching the svn repository
to see what was changed, find out what files have been moved,
and get a good overview of the situation. Needless to say, you
should be knowing what you are dealing with :)

> So I thought that if I
> imported the 1.2.12 code from the vendor into a vendor branch and
> copied it to a new directory (trunk/modules/module1_new) I could then
> overwrite the files in module1_new with the files from module1. I'd
> then move/overwrite the module1 dir with the module1_new dir. Now the
> module1 dir contains the history of changes we made since 1.2.12.

Simply importing the 1.2.12 code onto a vendor branch with "svn import"
will allow you to view the changes that have been made.
You don't need to merge or copy anything to do that.

You could do something like:

  cd project-1.2.12
  svn mkdir file://repo/vendor -m "creating dir for vendor branches"
  svn import file://repo/vendor/project -m "importing project 1.2.12"
  svn cp file:///repo/vendor/project file://repo/tags/project-1.2.12 \
          -m "tagging project 1.2.12"
  svn diff file:///repo/tags/project-1.2.12 file:///repo/trunk

The diff will be crazy though if you've moved lots of files.
Diffing only parts of the tree (were this makes sense) or even
diffing specific files may help to understand what has been
changed since you started hacking 1.2.12.

> Then, I could get their latest 1.2.16 release, add it to the vendor
> branch and merge changes between 1.2.12 and 1.2.16 on the vendor
> branch to the modules1 dir.

Use svn_load_dirs.pl to load the 1.2.16 release onto the vendor branch
and tag the new release.

Then view the diff between the releases so you know what svn will
try to apply to your source tree when you merge:

  svn diff file:///repo/tags/project-1.2.12 file:///repo/tags/project-1.2.16

Then try to merge the diff between pristine 1.2.12 and 1.2.16 into
your trunk:

  svn merge file:///repo/tags/project-1.2.12 \
             file:///repo/tags/project-1.2.16 \
              /path/to/working/copy

Again if you've moved lots of files you may need to manually sort
things out somehow. Once you've sorted out what should be were
and got rid of all conflicts, you can commit and your trunk will
have the 1.2.16 code built in.

> Maybe my understanding of the vendor branch is limited/warped

Yes, you should probably also refer to the book:
http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html

-- 
Stefan Sperling <stsp@elego.de>                 Software Developer
elego Software Solutions GmbH                            HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12        Tel:  +49 30 23 45 86 96 
13355 Berlin                              Fax:  +49 30 23 45 86 95
http://www.elego.de                 Geschaeftsfuehrer: Olaf Wagner

  • application/pgp-signature attachment: stored
Received on Mon Nov 26 16:26:25 2007

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.