techwiseman wrote:
> Symlinks:
[snip]
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
"svn:internals".
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