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