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.
---------------------------------------------------------------------
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-08 20:58:29 CEST