applying a merge on a non workingcopy

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

Hi!

I wonder why merge requires a workingcopy. Problem is, that I'm tracking a 
vendor's sources, and before loading a new version into the repository, I'd 
like to apply local modifications to those sources.

Maybe the way I want to work itself is flawed, I don't have a set opinion on 
that yet. 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 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.

thanks

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

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: applying a merge on a non workingcopy

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

-----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.

-----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.
---------------------------------------------------------------------

Dale


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