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

Re: howto 'retrofit' a vendor branch?

From: Ryan Schmidt <ryandesign_at_macports.org>
Date: 2007-08-28 09:08:09 CEST

On Aug 27, 2007, at 08:59, Aaron Bennett wrote:

> We've got a fairly hacked version of an open source package that we
> rely on. ( maia mailguard, as a point of interest ). The problem
> is, now that we've got it customized, the vendor has released at
> least two smallish-but-significant dot releases. We're running a
> customized 1.0.0 and current rev is 1.0.2. When I first hacked it,
> I just hacked each file as needed until it did what I wanted, as if
> I'd never heard of 'source control' or 'change management' before
> in my life. (!)
>
> Now, however, I want to bring my changed version of 1.0.0 up to
> 1.0.2. I'm not _entirely_ sure of what files I hacked in 1.0.0 --
> it's not a ton of them, but both the interface and the underlying
> stuff was modified quite a bit to fit into our environment and to
> satisfy the demands of our user support team.
>
> Sounds like a job for... SUBVERSION, right? RIGHT. Especially
> since the maia guys use svn to maintain the project.
>
> So I got svn installed and working and read the 'Version Control
> with Subversion' book on red-bean.com. Awesome book and many
> thanks to the authors, by the way. It seems to me after reading
> that I ought to treat the official dist of maia as a vendor branch
> in my main project.
> here's what I've done...
>
> 1. I created the suggested skeleton, maia/trunk , maia/branches,
> maia/tags, maia/vendor.
> 2. from my source directory, svn import https://svn/maia/trunk
> 3. grab maia 1.0.2 source, svn import https://svn/vendor/1.0.2
> 4. check out trunk as working copy svn co https://svn/maia/trunk;
> cd trunk
>
> ok, now here's where I get messed up -- time to merge, right?
>
> 4. svn merge https://svn/maia/vendor/1.0.2 https://svn/maia/trunk
>
> what I get is:
> [abennett_at_wide trunk]$ svn merge https://svn/maia/vendor/1.0.2
> https://svn/maia/trunk
> Skipped missing target: 'LICENSE'
> Skipped missing target: 'maia-mysql.sql'
> Skipped missing target: 'amavisd-maia'
> Skipped missing target: 'maia-pgsql.sql'
> Skipped missing target: 'amavisd.conf.dist'
> Skipped missing target: 'README'
> Skipped missing target: 'maia.conf.dist'
> Skipped missing target: 'reference'
>
> ( I don't understand that, I want to MERGE those missing files into
> the trunk... why is it skipping them? )
>
> then, instead of merging the vendor's changes on all of the files,
> it deletes all of the old files and replaces them with new ones. why?
>
> for example:
>
> D php/error.php
> D php/welcome.php
> D php/confirm.php
> D php/auth.php
> D php/adminhelp.php
> D php/xadminusers.php
> D php/mailtools.php
> D php/view.php
> D php
> A php
> A php/error.php
> A php/welcome.php
> A php/confirm.php
> A php/auth.php
> A php/adminhelp.php
> A php/xadminusers.php
> A php/mailtools.php
> A php/view.php
>
>
> I'm obviously missing something. I thought, maybe I'm going the
> wrong way, and I want instead svn merge https://svn/maia/trunk
> https://svn/maia/vendor/1.0.2 . but that doesn't work either... it
> correctly adds the new files, but still deletes all of the old
> stuff and re-adds it instead of merging.
>
> help! It's clear that I'm confused, that's all that's clear though.

You want to read the chapter in the book ( http://svnbook.org ) on
Vendor Branches.

You will want to ignore the fact that they use Subversion. Instead,
get exports or source tarballs of their 1.0.0 and 1.0.2 source code.
Import 1.0.0 into $REPO/vendor/mailguard/current using svn import.
Copy it to $REPO/vendor/mailguard/1.0.0 using svn cp. Now import
1.0.2 into $REPO/vendor/mailguard/current and copy it to $REPO/vendor/
mailguard/1.0.2 using svn_load_dirs.pl.

Now you can go into a working copy of your modified 1.0.0 code, and
ask Subversion to upgrade it to 1.0.2:

cd wc-of-your-code
svn merge $REPO/vendor/mailguard/1.0.0 $REPO/vendor/mailguard/1.0.2

Resolve conflicts, test, commit.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 28 09:07:02 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.