On Wed, Oct 15, 2008 at 1:28 PM, Hendrik Maryns
> Eelke Blok schreef:
>> On Wed, Oct 15, 2008 at 12:20 PM, Hendrik Maryns
>> <qwizv9b02_at_sneakemail.com> wrote:
>>> On second thought, it probably isn't. This is targeted at releases and
>>> how to stay up with them. But I do want to keep working 'on the
>>> bleeding edge': I want to be able to do svn up and get Jakarta's latest
>>> changes, then svn co and put them in my repo. Other collaborators
>>> would, of course, simply check out from my repo and don't bother with
>> Although the description in the documentation may be about "keeping up
>> with the bleeding edge", the principle of a vendor branch is much more
>> versatile. *You* choose *when* you merge *which* release into your own
>> Think of it this way. Let's say you could get your hands on patch
>> files between any one release of your base project (actually, you
>> could generate them yourself, if you had both versions of the
>> project). This would get you where you want to be also; you would:
>> - Keep track of the versions of the base project you merged into your
>> derived project
>> - When the time comes to do another synchronization with the base
>> project's code (be that the bleeding edge, or the latest stable
>> release, or whatever you like), you would get the correct set of patch
>> files, apply them to your project and make a note of this latest
>> version that you merged into your project.
>> This is exactly what a vendor branch does. Only it is much more conventient:
>> - You don't have to keep track of the various versions you
>> synchronized to your base project, the system does that for you (you
>> just need to make sure you tag the revisions where you did a merge to
>> be able to easily refer to them in the future).
>> - You don't need to fiddle around with patch files, SVN will generate
>> the patches for you and apply them, all in a single command.
> Well, yes, but it is inconvenient to go through this whole series of
> commands each time someone commits a change on the vendor side.
> Ideally, I'd just do svn up (and maybe resolve conflicts). Now I'd have
> to do svn up, copy over the changes to the vendor branch working copy,
> (since that is what this section boils down to:
>> To perform this upgrade, we checkout a copy of our vendor branch, and replace the code in the current directory with the new libcomplex 1.1 source code. We quite literally copy new files on top of existing files, perhaps exploding the libcomplex 1.1 release tarball atop our existing files and directories. The goal here is to make our current directory contain only the libcomplex 1.1 code, and to ensure that all that code is under version control. Oh, and we want to do this with as little version control history disturbance as possible.
> isn't it?), and finally svn merge (and maybe resolve conflicts).
I used to use SVK to do this. Normally SVK is a per-user tool but I
wanted a central repository with SVN and Subclipse in it in my case.
I used SVK on the repository server to regularly synch paths from
those repositories into a path in my repository. I can then use
normal SVN commands to make my own branch from one of those and merge
to pull changes from those paths into my branch.
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org
Received on 2008-10-15 13:40:19 CEST