On Tuesday 09 August 2011, Andreas Krey wrote:
> 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'[Note: I'm assuming you meant svn_load_dirs here] 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.
Yes, I am fully aware of all that, reread what I said: I warned the OP that
this is something that initially confused me when I first used svn_load_dirs.
The point is that svn_load_dirs is mentioned as a tool that helps maintaining
vendor branches. A common task in that context is to update your vendor branch
from a new upstream release. A requirement there is that local changes are
preserved through the update. svn_load_dirs doesn't help you with that, it
only changes "a branch to exactly the state an external directory
represents.". This is something that confused me when years ago I first
started creating a vendor branch of something. Reading the docs now, they have
improved in that aspect.
> Also, how do you think svn_load_dirs *should* do what you request?
Wearing a user's hat, the answer is that I don't care. Yes, this is a rather
naive approach, but why should I care how it works under the hood? I just need
my changes preserved!
Now, more practically speaking, I synced a directory to vendor-1.1. I then
made several changes and then sync to 1.2. The obvious approach is to first
upload the new 1.2 verbatim and then merge the changes made between the two
syncs one by one, optionally prompting the user. This is effectively what I do
manually now and there is no reason it couldn't be done automatically.
I'd even claim that this is superior to the documented approach of merging
1.1:1.2 into a local branch. The problem is that this is one big change that
often contains bugfixes that can be contained in the local branch. If upstream
slightly changed the code, like different formatting, comments, etc, applying
the big change on top will cause conflicts. Selecting the local changes to
apply on to of the new 1.2 version manually, possibly adjusting changes in
between has higher chances of success.
That said, I wouldn't say that it is svn_load_dirs that should do all this.
Firstly, it is a tool with a very clear goal (sync a directory) and adding
further features would be just bloat. Secondly, these are just merges and
those should be easy using _any_ SVN client, so improvements are better put
there than adding specializations in yet another tool.
> 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.
svnsync manages to find out when and where it last synced with, so why
shouldn't a vendor-branch management tool? You can always add a custom
property, infer the last sync from the checkin comment or prompt the user.
Cheers!
Uli
--
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
Received on 2011-08-09 11:27:31 CEST