[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 13:00:55 CET

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Sperling wrote:
> On Mon, Nov 26, 2007 at 10:22:34AM +0000, Nathan Watson-Haigh wrote:
>> Now, the questions I particularly have are:
>> 1) Are my code changes and file rearrangement supposed to go on the
>> vendor_branch?
>
> They aren't supposed to go on the vendor branch.
>
> You do not put your own changes onto the vendor branch.
> The vendor branch is just supposed to mirror what the
> vendor you are getting the code from is doing.
>
> All your own work happens on "trunk", and you merge from
> the vendor's code from the vendor branch into trunk.
>
> So every time you get a new vendor release onto your vendor branch,
> you merge the differences between the vendor's last release you've
> merged and the new one into your trunk, sort out the conflicts,
> and commit the result to your trunk.
>
> Hope this helps,

I haven't been editing the vendor_branch, so that's ok and clarifies a few points. Now, can I explain how I see this working and you can correct me if
I'm wrong.

So the current code in trunk/modules/module1/ is based on v1.2.12 of the vendor code and contains our own changes. Unfortunately, the history no
longer exists for the changes made to the v1.2.12 code (I think due to migrating from CVS). 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/
2a) overwrite the trunk/modules/module1 files with the current code (which is supposed to be based on 1.2.12) and commit the changes. This should give
me the change history from 1.2.12 and our current code for the module.
3) make modifications and file moves in trunk/modules/module1/
4) load the latest 1.2.16 vendor code using svn_load_dirs.pl into the vendor_branch
5) merge changes between the 1.2.12 tag and the 1.2.16 tag into trunk/modules/module1

Should this work as I expect/hope? Any complications/difficulties I might expect?

Cheers,
Nath
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHSrV39gTv6QYzVL4RAjRLAJsFmoqdWiG6M6v5ZQmxYydi26P1ugCfZZec
KfHp7H7wUc/hcSdhwqzL3WE=
=29u+
-----END PGP SIGNATURE-----

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