You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ewout ter Haar <ew...@gmail.com> on 2006/07/15 14:23:02 UTC

tracking of a third party svn repository

I am a svn newbie, and I am sure this must be
common knowledge, but I was not able to find
an answer, despite googling the words in the subject.

So: I want to track third-party software, which is
mantained in a svn repository, making my local
modifications, but tracking their updates.

I read about vendor branches
http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html
but this seems to cover the case where
the upstream package is not available via a
repository. As I understand it, svn_load_dirs.pl in particular
is meant to load unversioned trees into your own
repo.

But if I load a third-party package into my own
repository, with svn:externals maybe, then
I cannot do any merge operations, right?

I am sure I am missing something trivial. What is the
normal way people handle this situation?

Thanks very much in advance,

Ewout ter Haar

--

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: tracking of a third party svn repository

Posted by Ewout ter Haar <ew...@gmail.com>.
On 7/15/06, Ryan Schmidt <su...@ryandesign.com> wrote:

> It has been said on this list that Subversion was never intended to
> support cross-repository merging like this, that this use is
> unsupported, and the fact that it happens (or seems) to work when
> both repositories use the same protocol is an accident rather than a
> feature. IIRC, it was also stated that this was going to be disabled
> entirely in a future version of Subversion -- perhaps as soon as
> 1.4.0, I'm not sure.
>
> IOW, I don't know how to do what you want, though I too would like to
> know if there's a good answer.

All right, that´s a pity, I guess people do this with svk, bzr and all those
other systems I would like to have avoided learning. It seemed such
a common request.

> Where I work, we do use the vendor branch strategy. We download
> released tarballs of the 3rd-party projects we're interested in and
> bring them into the /vendor section of our own repository -- initial
> import using svn import, subsequent updates using svn_load_dirs.pl.
> When we want to make a version of one of those projects with a few
> local modifications, we copy the project out of /vendor to some other
> path in the repository (usually under a directory for whatever
> customer we're doing this for -- for example yesterday I helped a
> coworker set up a modified version of phpBB for one of our
> customers). Local modifications can then take place in that copied
> directory, and the modified project can be deployed from there. As
> soon as we want to merge in a newer version of the upstream code,
> that's no problem. First, we load it into /vendor with
> svn_load_dirs.pl, then we merge the changes from there into the copy
> in the customer's directory.

Thanks! I guess it is not a lot of work to do an export - svn_load_dirs -
merge - cycle every once in a while.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org


Re: tracking of a third party svn repository

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jul 15, 2006, at 16:23, Ewout ter Haar wrote:

> I want to track third-party software, which is
> mantained in a svn repository, making my local
> modifications, but tracking their updates.
>
> I read about vendor branches
> http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html
> but this seems to cover the case where
> the upstream package is not available via a
> repository. As I understand it, svn_load_dirs.pl in particular
> is meant to load unversioned trees into your own
> repo.
>
> But if I load a third-party package into my own
> repository, with svn:externals maybe, then
> I cannot do any merge operations, right?
>
> I am sure I am missing something trivial. What is the
> normal way people handle this situation?

Currently, you can only do a merge from a remote repository into a  
working copy from your repository if the exact same protocol is used  
for both repositories (both use https, for example, or both use svn 
+ssh). If the protocols differ, you get a message that cross-protocol  
operations are not supported.

It has been said on this list that Subversion was never intended to  
support cross-repository merging like this, that this use is  
unsupported, and the fact that it happens (or seems) to work when  
both repositories use the same protocol is an accident rather than a  
feature. IIRC, it was also stated that this was going to be disabled  
entirely in a future version of Subversion -- perhaps as soon as  
1.4.0, I'm not sure.

IOW, I don't know how to do what you want, though I too would like to  
know if there's a good answer.

Where I work, we do use the vendor branch strategy. We download  
released tarballs of the 3rd-party projects we're interested in and  
bring them into the /vendor section of our own repository -- initial  
import using svn import, subsequent updates using svn_load_dirs.pl.  
When we want to make a version of one of those projects with a few  
local modifications, we copy the project out of /vendor to some other  
path in the repository (usually under a directory for whatever  
customer we're doing this for -- for example yesterday I helped a  
coworker set up a modified version of phpBB for one of our  
customers). Local modifications can then take place in that copied  
directory, and the modified project can be deployed from there. As  
soon as we want to merge in a newer version of the upstream code,  
that's no problem. First, we load it into /vendor with  
svn_load_dirs.pl, then we merge the changes from there into the copy  
in the customer's directory.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org