You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Fa...@ses-engineering.com on 2008/07/08 10:16:25 UTC
Subversion's best-practice
Hello,
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?
Thanks & Best Regards,
Fabien.
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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion's best-practice
Posted by Florian Seydoux <fl...@gmail.com>.
Fabien.Bouleau@ses-engineering.com wrote:
> [...]
> 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.
It's exactly the way we go with my group: (so it's sound good to me)
third-party wich are deployed through source are integrated (source
only) using the
'vendor-branch' concept on our main repository (if needed), any binary
deployment
(of the third party, but also some local libs, with a low release
frequency) are hosted
on (currently) one alternat. repo (staging area);
a set of "svn:external" (from the main repo) help us to co a working
build tree.
like this, the depot of binaries can be splitted, hosted on separate
machine, etc,
without disturbing (so much) the main area.
regards
florian
--
--------------------------------------------------------------------
Seydoux Florian
http://www.spinx-technologies.com
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion's best-practice
Posted by Kevin Grover <ke...@kevingrover.net>.
On Tue, Jul 8, 2008 at 11:57 AM, Ryan Schmidt
<su...@ryandesign.com> wrote:
> On Jul 8, 2008, at 05:16, Fabien.Bouleau@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@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Yeh, but the OP said that the third-party libraries are in binary
form. Which implies (to me) no source. So, unless someone wants to
go in an tweak the binaries, I think his scheme makes sense.
If it's not painfully obvious, the 'tweak the binaries was a joke', I
have a special stick to hit people with should that try it.
- Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion's best-practice
Posted by Fa...@ses-engineering.com.
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 <su...@ryandesign.com> wrote on 08/07/2008
20:57:49:
> On Jul 8, 2008, at 05:16, Fabien.Bouleau@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion's best-practice
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jul 8, 2008, at 05:16, Fabien.Bouleau@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org