using svn:externals in third_party

[Mike Samuel]

Instead of checking a large part of large libraries like appengine and
webdriver into third_party, can we use svn:externals ?

Note specifically the third-party/skins/toolkit example below with a
revision number form http://svnbook.red-bean.com/en/1.0/ch07s03.html :

It can be set on any versioned directory, and its value is a
multi-line table of subdirectories (relative to the versioned
directory on which the property is set) and fully qualified, absolute
Subversion repository URLs.

$ svn propget svn:externals calc
third-party/sounds http://sounds.red-bean.com/repos
third-party/skins http://skins.red-bean.com/repositories/skinproj
third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker
The convenience of the svn:externals property is that once it is set
on a versioned directory, everyone who checks out a working copy with
that directory also gets the benefit of the externals definition. In
other words, once one person has made the effort to define those
nested working copy checkouts, no one else has to bother—Subversion
will, upon checkout of the original working copy, also checkout the
external working copies.

[๏̯͡๏ Jasvir Nagra]

This sounds good to me provided we use an explicit version for all externals we use.  Presumably we don't do this for all third_party code - only those that we don't modify and that are available via svn.

This particular benefit isn't so much of a win in our case right?  The only really useful checkout is /trunk which already contains third_party.

 

[Mike Samuel]

2009/12/11 ๏̯͡๏ Jasvir Nagra <jas...@google.com>:

> This sounds good to me provided we use an explicit version for all externals
> we use.  Presumably we don't do this for all third_party code - only those
> that we don't modify and that are available via svn.

Yes. Explicit versions for all.

> On Thu, Dec 10, 2009 at 12:41 PM, Mike Samuel <mikes...@gmail.com> wrote:
>>
>> Instead of checking a large part of large libraries like appengine and
>> webdriver into third_party, can we use svn:externals ?
>>
>> Note specifically the third-party/skins/toolkit example below with a
>> revision number form http://svnbook.red-bean.com/en/1.0/ch07s03.html :
>>
>> It can be set on any versioned directory, and its value is a
>> multi-line table of subdirectories (relative to the versioned
>> directory on which the property is set) and fully qualified, absolute
>> Subversion repository URLs.

>> $ svn propget svn:externals calc
>> third-party/sounds             http://sounds.red-bean.com/repos
>> third-party/skins
>>  http://skins.red-bean.com/repositories/skinproj
>> third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker
>> The convenience of the svn:externals property is that once it is set
>> on a versioned directory, everyone who checks out a working copy with
>> that directory also gets the benefit of the externals definition. In
>> other words, once one person has made the effort to define those
>> nested working copy checkouts, no one else has to bother—Subversion
>> will, upon checkout of the original working copy, also checkout the
>> external working copies.
>
> This particular benefit isn't so much of a win in our case right?  The only
> really useful checkout is /trunk which already contains third_party.

Yeah. The things that make upgrading hard are:
(1) keep track of where it came from
(2) tracking down the license and README
(3) putting all the jars in the right place
(4) wiring the jars into the classpath in build.xml

svn:externals is much better about 1, pretty good about 2, may help
with 3 for some projects, and not for others, and does nothing for 4.

[๏̯͡๏ Jasvir Nagra]

    (5) fixing api changes between versions (hence the need for explicitly named versions)

svn:externals is much better about 1, pretty good about 2, may help
with 3 for some projects, and not for others, and does nothing for 4.

Nor 5. 

[Mark Seaborn]

Mike Samuel <mikes...@gmail.com> wrote:

> Instead of checking a large part of large libraries like appengine and
> webdriver into third_party, can we use svn:externals ?

I don't know if any of you use Caja SVN with a DVCS such as Git or
Mercurial, but I suspect svn:externals doesn't interact very well with
those systems because they don't have a generic way of representing
Subversion properties.

Chromium uses depot-tools/gclient [1] to fetch dependencies, which is
loosely equivalent to svn:externals except that the external
repositories are listed in a normal file (called DEPS) rather than in
special properties. Since this tool is not part of Subversion it can
be a bit more flexible. It lets you override dependencies and fetch
them selectively. On the other hand, it is an extra tool that you
have to install.

Mark

[1] http://www.chromium.org/developers/how-tos/depottools/gclient
http://www.chromium.org/developers/how-tos/install-gclient

[Mike Samuel]

2009/12/29 Mark Seaborn <m...@mythic-beasts.com>:

> Mike Samuel <mikes...@gmail.com> wrote:
>
>> Instead of checking a large part of large libraries like appengine and
>> webdriver into third_party, can we use svn:externals ?
>
> I don't know if any of you use Caja SVN with a DVCS such as Git or
> Mercurial, but I suspect svn:externals doesn't interact very well with
> those systems because they don't have a generic way of representing
> Subversion properties.
>
> Chromium uses depot-tools/gclient [1] to fetch dependencies, which is
> loosely equivalent to svn:externals except that the external
> repositories are listed in a normal file (called DEPS) rather than in
> special properties.  Since this tool is not part of Subversion it can
> be a bit more flexible.  It lets you override dependencies and fetch
> them selectively.  On the other hand, it is an extra tool that you
> have to install.

It definitely is nice to have a single checkout that gets everything.
But if most of our clients and potential clients use a DVCS then it
doesn't gain much.
Is the DEPS file format pretty standard across DVCS systems?

[Mark Seaborn]

Mike Samuel <mikes...@gmail.com> wrote:

> 2009/12/29 Mark Seaborn <m...@mythic-beasts.com>:

> > Chromium uses depot-tools/gclient [1] to fetch dependencies, which is
> > loosely equivalent to svn:externals except that the external
> > repositories are listed in a normal file (called DEPS) rather than in
> > special properties.  Since this tool is not part of Subversion it can
> > be a bit more flexible.  It lets you override dependencies and fetch
> > them selectively.  On the other hand, it is an extra tool that you
> > have to install.
>
> It definitely is nice to have a single checkout that gets everything.
> But if most of our clients and potential clients use a DVCS then it
> doesn't gain much.
> Is the DEPS file format pretty standard across DVCS systems?

No, it's not standard; gclient is just a tool that was hacked up for
Chromium and AFAIK it is only used by Chromium and Native Client. I
think it's a good idea in principle but if you're happy with SVN it's
probably not worthwhile using it for Caja.

Mark