[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: the state of thought on inter-/intra- project linking/sharing/externals

From: Molle Bestefich <molle.bestefich_at_gmail.com>
Date: 2005-12-30 00:03:43 CET

techwiseman wrote:
> Symlinks:

All points agreed to, symlinks are sort of a bad solution.

> svn:externals
> The alternative to symlinks is svn:externals. svn:externals is implemented
> WITHIN subversion, so it is much closer to what the problem we're trying to
> solve, but it too has some issues:
> 1) svn:externals only supports directories, not individual files (I suspect
> this has something to do with having a single .svn subdirectory in each
> directory, but please comment.)

Not sure, there's probably some technical reason.
I don't think sharing a single file is a common case, and it does
sound like it would get messy easily, so probably all for the better
if you ask me.

> 2) commits aren't recursive. (how about updates? etc?) I can immagine
> situations where you may want recursive or non-recursive commits. should
> this be added, perhaps, as a per-external setting?

Agreed, commits should be atomic if the svn:external points to
something inside the repository itself.

Would need to make the code know whether the svn:externals is really internal.
Either by adding support for relative paths, eg. starting with /
instead of <protocol>://, or by creating a new property

I imagine that "svn:internals" is the nicer solution.
There might be less shortcuts in the code, it'll probably be a few
lines extra in fact, but explaining and documenting things should be
much more straightforward.

> 3) URLs need to be absolute, making self-referential projects more work to
> update in the event of a directory layout change.

Or changes in host name. Or port. Or access method (svn://, http://).

And it doesn't work if a user can only access via http and the ref
says svn://, but that's another problem (which nobody has complained
about as far as I know, so who cares ;-)).

> Again, these aren't criticisims or value judgements, I'm simply trying to
> document what I think I know, so I can get corrections, and clarifications
> about WHY the status quo is as it is.

I imagine it's like it is because some svn developer conjured up
svn:externals for his particular purposes, and it just happens to be
that out in the wild there were vastly more users that needed
svn:externals for something else than what it was made for.

> Hopefully this will cultivate some
> useful discussion on how these features SHOULD work, and give me (or some
> other developer) some direction in creating a patch to add capibilities to
> subversion.

As a heavy svn:externals user, I for one would much appreciate a patch.

Here's a couple more things to consider:

 * Users forget to pin the externals when they're tagging.

   Nothing big, it can be done later.
   But it would be nice with a --pin-externals option to 'svn cp' that
pinned externals to HEAD revision.

 * Cumbersome to hotfix projects using svn:externals.

   If you tag one of your projects and the project has svn:external
folders, you cannot modify something in the svn:external folder and
commit it because the externals will be pinned in the tag.

   Easy to work around too - remove the external, make a copy instead
and modify that.
   Just thought I'd bring it up as a possible thing to consider.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 30 00:04:27 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.