-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Stefan,
I really appreciate your help - thanks! :)
Stefan Sperling wrote:
> 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?
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 :)
I have a reasonable idea of what's changed, just in case it useful:
1) All files in an "upload" subdirectory were moved to its parent dir. This accounts for about 90% of the files in the release.
2) A couple of files were added
3) Many files had several small changes
>
>> 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
>
I'm gonna give this a try by setting up a local repo - since I don't care about the history (at this point in time) I'll import files from an "export"
of our code.
> 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.
I think it's this step where it got complicated last time. It complained about not being able to find the files in the "upload" dir. This was because
in trunk, it's contents were moved to it's parent dir. Any thoughts on making this less laborious in future?
>
>> 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
>
Yeah, I've looked but I was still confused :( I'll let you know how I get on.
Cheers,
Nathan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHSvE89gTv6QYzVL4RAlz1AKDTWFESJwBfDZvnJ/qamQOrkog87gCfTB5O
CDDaIAeg3GX+o3wqdsD8xB0=
=zDWO
-----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 17:16:29 2007