What about putting the vendor project in the third-party repository with a
svn:externals and export it to a vendor branch of the specific repository
in case modifications are needed? (you include it in your repository only
if absolutely required).
Or (more advanced magic) imagine the situation where you have the sources
of a third-party tool and you want to introduce your own modifications:
TP-REPOS:
/vendor
/tptool
/trunk
/tags
/3.0
MY-REPOS:
/vendor
/tptool-with-modifs
/original (defined as a svn:externals reference to
svn://server/TP-REPOS/vendor/tptool/trunk
/modifs (contain only the modified files)
/trunk (application that uses the tptool)
/branches
/tags
The MYREPOS/vendor/tptool-with-modifs/modifs folder contains the modified
files for the tp-tool. The Makefile is consequently modified so that the
files in the modifs folder shadow the original files. Put it another way,
you define a search path.
Fabien.
Ryan Schmidt <subversion-2008c_at_ryandesign.com> wrote on 08/07/2008
20:57:49:
> On Jul 8, 2008, at 05:16, Fabien.Bouleau_at_ses-engineering.com wrote:
>
> > I am currently facing a problem with Subversion's best usage with my
> > co-workers. We are working on various projects, i.e. we have more
> > than 20
> > Subversion repositories. And of course we are using third-party
> > APIs and
> > tools.
> >
> > According to the documentation, there is the vendor branch development
> > scheme. I have some concern about putting the APIs and third-party
> > tools as
> > such because:
> >
> > 1. The third-party APIs and tools uploaded are binary.
> > 2. They are not intended to be modified but used off-the-shelf.
> > 3. Binaries make the repository grow like Hell
> > 4. Different projects (repositories) may use the same third-party
> > APIs and
> > tools and duplication makes my teeth screech.
> >
> > Therefore I had the following idea: to setup a "third-party" repostory
> > where we would drop the third-party binaries and sources as vendor
> > branch
> > to keep track of the versions (using tags) and refer to it from the
> > various
> > projects using svn:externals.
> >
> > Does that sound correct to you? Any other suggestion?
>
> Sometimes I want to modify vendor projects slightly. To do this, I
> "svn cp" them from their location in the vendor directory to a
> location in my project. Then I modify them. Then later I can use "svn
> merge" to update my copy to a newer upstream release.
>
> But this is only possible if your project is in the same repository
> as the vendor projects. So if you think there's a chance you would
> ever want to slightly modify a vendor project, you should seriously
> consider keeping your vendor projects in the same repository as your
> own projects, and not in a separate repository.
>
DISCLAIMER:
This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-09 18:19:19 CEST