[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: Nathan Watson-Haigh <nathan_at_watsonhaigh.net>
Date: 2007-11-26 15:39:13 CET

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.

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

My aim is to allow us to incorporate future changes (more easily than is currently possible) made by the vendor into our code so we can continue to
offer additional features to our own users.

Maybe my understanding of the vendor branch is limited/warped so please feel free to tell me if what I'm trying to do is wrong/not possible!


Stefan Sperling wrote:
> On Mon, Nov 26, 2007 at 12:00:55PM +0000, Nathan Watson-Haigh wrote:
>> So the current code in trunk/modules/module1/ is based on v1.2.12 of
>> the vendor code and contains our own changes.
> OK.
>> Unfortunately, the history no
>> longer exists for the changes made to the v1.2.12 code (I think due to
>> migrating from CVS).
> I don't get what you want to achieve and where you are starting from.
> Isn't the 1.2.12 code already on the vendor_branch?
> Or is there some other version sitting on the vendor branch?
> And you want to retroactively recreate the pristine 1.2.12 version
> on your vendor branch? In this case, what do you think should happen
> to the code that currently sits on the vendor branch, if any?
> Or is the vendor branch empty?
>> So if I:
>> 1) Load v1.2.12 vendor code into the vendor_branch and tag it using
>> svn_load_dirs.pl.
>> 2) svn copy the 1.2.12 tag to trunk/modules/module1/
> The point of the vendor branch is simply to allow you to
> a) create meaningful diffs containing all or a selection
> of your changes to upstream code
> b) be able to relatively easily track what changes are
> made upstream and merge those changes into your code base
> if you want/need them
> Which of these do you want to achieve by importing unmodifed 1.2.12
> code into the vendor branch and then *copying* that to your trunk?
> Especially given that your trunk seems to already contain the upstream
> 1.2.12 code?
>> 3) make modifications and file moves in trunk/modules/module1/
> If you can avoid moving files around, don't do it.
> Merging new upstream changes into your trunk will become much
> harder if you do this.

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 26 15:39:32 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.