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
Received on Mon Dec 13 09:52:55 2004