[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Vendor branches vs. svn merge (across repositories) - almost

From: Ryan Schmidt <subversion-2008c_at_ryandesign.com>
Date: Mon, 8 Sep 2008 12:17:51 -0500

On Sep 8, 2008, at 7:18 AM, Ingo Zitzmann wrote:

> i went through the open issues tracker http://subversion.tigris.org/
> issues/buglist.cgi looking for merge and add. Also I followed the
> guide here http://svnbook.red-bean.com/en/1.1/ch07s05.html but
> unfortunately without the desired result.

That book is for Subversion 1.1. You would do better to refer to the
book for 1.4:

http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html

Or the not-yet-finished book for 1.5:

http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html

> The issue I am facing is that new files won't be added despite the
> statement that it should be fixed as of 1.5.0: http://merge-
> tracking.open.collab.net/ds/viewMessage.do?
> dsForumId=57&dsMessageId=52380
>
> Use case is:
>
> I have a web application provided by a third party vendor. I take
> it customize it and store it in a separate repository. I setup a
> vendor repository (not only a different folder in the applications
> repository) according to the example in the svnbook but only with
> the result that new files are _not_ added (according to the thread
> on collab.net this should work).
>
> The setup is the following:
> * 1 vendor repository with webapp
> * n application repositories with customized webapp
> * vendor goes from version 2.0 to 2.1
> * application does the following to fully replace specific
> subdirectories with the new vendor version (no need to diff e.g.
> images)
> cd local-dev/webapp/vendordir
> svn merge --ignore-ancestry http://svn-vendor/vendor/webapp/2.0/
> vendordir http://svn-vendor/vendor/webapp/2.1/vendordir --accept
> theirs-full
> * directories which have changes within the custom directories then
> are to merged as expected
> cd local-dev/webapp/customdir
> svn merge --ignore-ancestry http://svn-vendor/vendor/webapp/2.0/
> customdir http://svn-vendor/vendor/webapp/2.1/customdir
>
> Key items are:
> * work across repositories
> * Do a full replace (internal delete + add during merge) upon
> request (--accept theirs-full)
> * Add missing files
>
> In the end, everything is there and it should work but it is not
> working "as advertised". For me that would be a compelling
> "convenience" function to have an edge over CVS from the usability
> point of view.
>
> Can anyone confirm that this should work or is it a bug? To me this
> would be an awesome functionality to keep (parts of) projects in
> sync with another.

It has always been my understanding that merging across repositories
is not supported. Nobody contradicted me when I said this here before:

http://svn.haxx.se/users/archive-2008-08/0932.shtml

http://svn.haxx.se/users/archive-2008-08/0087.shtml

http://svn.haxx.se/users/archive-2008-06/0013.shtml

http://svn.haxx.se/users/archive-2008-05/0671.shtml

The thread you found on the merge tracking forum is interesting in
that it shows that the devs have committed changes which fix some
problems with cross-repository merging (though perhaps not yet all
problems). Particularly thsse messages:

http://merge-tracking.open.collab.net/ds/viewMessage.do?
dsForumId=57&dsMessageId=51902

http://merge-tracking.open.collab.net/ds/viewMessage.do?
dsForumId=57&dsMessageId=51919

http://merge-tracking.open.collab.net/ds/viewMessage.do?
dsForumId=57&dsMessageId=52380

Perhaps one of the devs would comment on the current status of the
supportedness of cross-repository merging, and any intended future
changes to this policy.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-08 19:18:16 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.