Hi Molle
Except in the case of 'svn cp' to branches or tags.
When you branch or tag, you want an actual repository copy of your
common files, fixated at the version that is in use when you release
(or branch).
Sometimes (albeit more rarely) you want to do a copy where you copy
the link as a link instead of fixating it. So there should be an
option to 'svn cp' to do that too.
I understood the first behavior. But the second one isnt clear. The
more useful behavior is if "svn cp" is done recursively on all the
dependent modules. If that is what you meant by the second point, then
its fine. Otherwise, we have 3rd variety i guess, in which case i'd
like to understand how copying the information as a link would be
useful.
Some people are concerned about the number of commands in 'svn', but I
hope they'll just shuffle things into 2, 3 or 4 categories and |more
the 'svn help' output when it's more lines than the screen can cope,
and thus have room for this command.
I'm not one of them :). You either have more commands or more options
per command :), because you still have to get the various jobs done.
Storing it as an actual file in the repository sounds like an odd idea.
I can't see the advantage of that vs. just using a non-inheritable property.
meta-file was only a suggestion. I'm ok with a property as well. In
that case i suppose a directory entry would be created and the property
would apply to that, correct?
Thanks
Prasad
Molle Bestefich wrote:
Narayana Prasad wrote:
But the common code must stay common and
maintain a common history.
Except in the case of 'svn cp' to branches or tags.
When you branch or tag, you want an actual repository copy of your
common files, fixated at the version that is in use when you release
(or branch).
Sometimes (albeit more rarely) you want to do a copy where you copy
the link as a link instead of fixating it. So there should be an
option to 'svn cp' to do that too.
It seems svn doesnt yet have a way to do this yet.
No, but it sure would be great to have :-).
I'd like to add an "svn link" command(along the lines of ln -s).
Sounds reasonable. That command would be something that most people
can understand from just looking at it.
Some people are concerned about the number of commands in 'svn', but I
hope they'll just shuffle things into 2, 3 or 4 categories and |more
the 'svn help' output when it's more lines than the screen can cope,
and thus have room for this command.
Example:
$ svn link /path/to/realdir linkdirname
Simple, therefore beautiful.
This command create a meta-file which will be subversion link
to a subversion directory in the same repository.
Storing it as an actual file in the repository sounds like an odd idea.
I can't see the advantage of that vs. just using a non-inheritable property.
It would of course be neat if the file could be checked out as an
actual unix symlink, but:
1.) Windows does not have symlinks (except Cygwin, which doesn't count).
2.) The current working copy has a 'severability' feature, which
would not work with symlinks.
I think the best way forward is to add the following features:
a.) 'svn:externals' property support for relative paths (eg. no
server FQDN, protocol and port numbers).
b.) Atomic commit, update, etc. support for the _relative_ svn:externals.
c.) An addition to 'svn cp' to fixate the links when branching and tagging.
Point a.) and b.) is good reasons to make a new property, named
'svn:internals' or 'svn:link'.
It's a lot easier to document that svn:{links/internals} are atomic
while svn:externals are not than starting to explain that "only when
using relative paths is the operation atomic..."
Regarding c.), the command to fixate could be named '--pin-internals',
'--fixate-internals', 'fixate-links', whatever. From a usability POV
it would be best if this was the default behaviour and there was a eg.
'--no-internals-fixate' option, but I'm not sure this would go down
well due to compatibility concerns.
HTH
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 7 12:43:42 2005