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
> Jakarta.
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
project.
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.
Good luck,
Eelke
---------------------------------------------------------------------
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:19:59 CEST