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