Re: vendor branch questions

Garrett Rooney <rooneg@electricjellyfish.net> writes:
> [Discussion of method deleted]

I have taken a different approach in my experimenting with subversion
as a tool for tracking my Debian packages.

The idea I had was that you have a single branch for the upstream
(vendor, whatever) source, and you simply tag the upstream releases.

This made merging the changes from the upstream into the trunk very
easy, etc. The _only_ problem I had was that I had to patch to get
the a new upstream version.

So, what I would do (in heavily shorthanded form) is:

svn import whatever/upstream
svn cp whatever/upstream whatever/tags/upstream_1.0
svn cp whatever/upstream whatever/trunk
svn co whatever/trunk
mangle away, etc.
svn commit
svn cp whatever/trunk whatever/tags/myversion_1.0-1

When a new upstream version comes out:

svn co whatever/upstream
apply diffs to bring up to current upstream
svn commit
svn cp whatever/upstream whatever/tags/upstream_1.1

In the trunk:

svn merge -rold:new whatever/upstream
<deal with possibly removed files, conflicts, etc>
svn commit

This seems "more subversiony" to me---I mean, by doing the imports to
whatever/upstream/version, it seems to me you're basically putting
them in separate branches---suggesting that there's no relationship.
What I tried seems to more accurately model the actual state of
affairs---that these are related revisions along one branch of
development.

My only complaint, at a practical level, is that I would like svn
import to do the diffing and commiting for the new upstream version
from an unversioned subdirectory---but doing it by hand isn't exactly
hard.

So what have I missed?

Mike.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 22 16:58:30 2002