Vendor braches [Was: Re: applying a merge on a non workingcopy]

[Ulrich Eckhardt <ec...@satorlaser.com>]

Dale Worley wrote:
> -----Original Message-----
> From: Ulrich Eckhardt [mailto:eckhardt@satorlaser.com]
>
> The thing I need is to provide some libraries to my fellow developers here,
> possibly with changes that have not (yet) been merged upstream. If there's
> an easier way to track external sources and still preserve local changes
> I'm all open ears.
> ---------------------------------------------------------------------
>
> You've already mentioned the solution that works well, maintaining a
> "vendor branch" structure.  With any other method, you don't keep a full
> record of the various different versions of the libraries.

Is there a precise definition of vendor-branch structure? I know the part in 
the book that speaks about 'vendor branches', but:

> -----Original Message-----
> From: Ulrich Eckhardt [mailto:eckhardt@satorlaser.com]
>
> However, I don't like the way it is described in chapter 7 of The
> Book: I don't have a copy of the external sources in any of my own
> projects, so there is no URL I could use to tell 'svn merge' what changes
> to incorporate when dropping a new vendor release.
> ---------------------------------------------------------------------

The problem I have with the approach in the book is that I don't know what 
parts have what meaning. Maybe it's just not described clear enough, maybe 
it's not universal enough, maybe I don't understand.
So, here a few more questions on that approach:
Assuming I have the mentioned 'current' and 'version-x.y', is either of those 
supposed to be immutable? Are even all of them supposed to be exactly the 
same as the vendor sources they were created from? Where should my local 
changes go to?

Uli

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Vendor braches [Was: Re: applying a merge on a non workingcopy]

[Dale Worley <dw...@pingtel.com>]

The crux of the "vendor branch" system is that there are two main threads of development.  One is your current code.  It evolves in the normal manner.  The "vendor branch" evolves, but successive revisions are successive releases of the code by the vendor.  When the vendor produces a new version, you check it in as a revision of the vendor branch, then merge that delta of the vendor branch into the branch that contains your code.

The remainder of the vendor branch structure is just setting up tags to record the names of the vendor's releases and to record the merges.

Dale

-----Original Message-----
From: Ulrich Eckhardt [mailto:eckhardt@satorlaser.com]

Is there a precise definition of vendor-branch structure? I know the part in 
the book that speaks about 'vendor branches', but:


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org