On Tue, 09 Aug 2011 09:20:17 +0000, Ulrich Eckhardt wrote:
...
>
> Yes I am. You might question whether it is reasonable to make them here, but
> it doesn't matter. The point is that you use svn_load_dirs not in order to
> just mirror the upstream sources locally, you could use a simple shared
> directory for that. No, you typically want to modify those sources, like adapt
> them to your company's build system or similar requirements.
>
> Now, these changes must be applied to any upstream release before you can use
> it and the astonishing part to me was that svn_load_dirs doesn't help you at
> all with that.
No, 'svn' ist supposed to help you with that. You keep a branch that only
contains the upstream updates, and repeatedly merge that into the branch
that you use to modify the vendor's sources to suit your needs. The
process of integration your modifications with a new upstream release
is called 'merging', which is something svn can do itself.
What svn can't do is exactly the history-preserving directory mirroring
*into* subversions, that, and only that, is what svn_load_dirs is for:
Change a branch to exactly the state an external directory represents.
Also, how do you think svn_load_dirs *should* do what you request? In
your scenario it works on a sandbox that contains the last vendor
release along with your changes on one hand, and it has the current
vendor release on the other hand. How should it decide what of the
changes between the two are vendor updates (to be taken from the new
vendor release) and what are your changes (to be kept)?
Simply to do that it would not only need to look into the svn history
of your single branch, but also discern which of the commits were
for your local adaption and which were vendor updates.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Received on 2011-08-09 10:01:32 CEST