Hi Moelle
It's a sort of "don't follow symlinks when copying, just make a copy
of the darn symlink itself" option.
It doesn't seem wildly useful since 'svn cp' is mostly used to branch
or tag, but there might be someone who wants parallel development
branches or what not, and they should have the possibility of 'raw'
svn cp.
Thats the same as not changing the link property when
tagging/branching. The link will continue to point to the head
revision(if that is what it was set to initially) in the tag or branch.
I have no objections to such a switch.
I'm not sure what you mean by "dependent modules".
same as common code. Sorry for introducing extra terms.
There's relatively easy ways to do that. You could:
* Rename the property to 'svn:fixated-links' on the destination
(parent) folder.
* Add a word for each link in the property, eg. ' fixated '.
I didnt understand the need to change the property name.
The rest of what you said was very arcane to me. Perhaps you are
describing situations that i'm unable to imagine. So just to be
clearer, i'd like to describe the series of actions and effects as i
visualize it.
NC=Non-Common
CO=Common
$ svn import NCdir URL/NCdir
$ svn import COdir URL/COdir
$ svn co URL/NCdir
$ svn co URL/COdir
$ svn link <PATH>/COdir NCdir/COdir <- there is now a
"real" directory(not symlink) inside NCdir which empty, which has
the link property set. PATH
can be relative to NCdir or absolute from repo
root(if it starts with /).
$ svn commit URL/NCdir <- Commits the link created
above into the server. The server now knows of a
directory with a link
property with value to <PATH>/COdir.
$ svn up NCdir <- Now the NCdir/COdir should
be populated with files from COdir
$ svn cp NCdir URL/branches/bNCdir <- Now there is branch in the
repo call bNCdir, which contains a directory called
COdir. However the link
property is set to branches/bCOdir. The bCOdir is created
as part of the svn cp
command. There is a switch available to the cp command to
skip-links if need be(perhaps
the user can be thrown a dialogue to choose which
links to branch)
$ touch NCdir/COdir/file
$ svn add NCdir/COdir/file
$ svn status <- An L flag should appear
against file, along with the A flag
$ svn commit URL/NCdir <- file should be committed
to <PATH>/COdir
$ svn co URL/branches/bNCdir <- The file committed above
should NOT appear in this checkout. However, if
skip-links was given during
the svn cp above, then it will appear.
The gist of this is that COdir is symlink for SVN and a directory for
the OS. SVN already knows how to traverse symlinks as identified by the
OS. The link property will act as one such identifier.
I'm still not conversant with the command syntax. So hope there arent
any mistakes.
Thanks
Prasad
Molle Bestefich wrote:
Russell Hind wrote:
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).
Yes, we use externals for 'proper' externals in another repo, and for
links to common code in the same repo. For the proper externals, on a
copy we'd like to be able to have the -r automatically added to the
external, but with the externals in the same repo, a copy would be required.
Currently we have to do this manually for all our externals when
branching for a release which isn't that usable.
Oh yeah. Fixating real _external_ svn:externals is very useful too.
Guess I sort of skipped over that point, *whistle hum* :-).
(I fixate about 30 svn:externals with -r on a monthly basis btw, but
none of them are really external per se.)
Narayana Prasad wrote:
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.
It's a sort of "don't follow symlinks when copying, just make a copy
of the darn symlink itself" option.
It doesn't seem wildly useful since 'svn cp' is mostly used to branch
or tag, but there might be someone who wants parallel development
branches or what not, and they should have the possibility of 'raw'
svn cp.
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.
I'm not sure what you mean by "dependent modules".
But I agree that svn cp could recursively copy the linked-to items as
a means of fixating (instead of just copying the property which would
be the 'raw' copy method).
Only obvious thing to consider with this method is that while we'd
like to do a repository copy of the folders and files, we would also
like to pertain the property that tells us that it actually is (or
rather was) a link.
There's relatively easy ways to do that. You could:
* Rename the property to 'svn:fixated-links' on the destination
(parent) folder.
* Add a word for each link in the property, eg. ' fixated '.
But here comes the hard part of the deal:
The problem arises when you realize that fixating a particular
revision has another use besides making sure that the correct versions
are referenced by your release in /tags/whatever-version. It is very
often useful to be able to later apply changes to the fixated files.
It's useful both for branches where active development happens, and
for tags where you might need to hotfix the common code. And it's
actually useful for *real* svn:externals too. And *that's* hard to
implement. Or hard-ish to implement in a good way, at the least :-).
There are three obvious ways around this problem:
1.) Do not support fixating real, external svn:externals.
2.) Make a hardcopy in the repository of the external files.
3.) Store diffs in the local repo against the files in the external repo.
2. is not pretty because it's a waste of space that 'svn cp' usually
does not do.
3. is not pretty because you don't know if they decide to 'svnadmin
obliterate' a revision and bring it back up or some such sheenanigans.
OTOH, that's less of a concern, since they might do that anyway as
things are right now (with dump and load), in which case they would
disturb svn:externals fixated with '-r'. (Seems the only way forward
for 'svn obliterate' and such is to support repositories where there
are holes in the revision numbers, but that's another discussion..)
I'd recommend to go with 1.), but make sure that the concept and
syntax is extensible to real svn:externals so a similar feature can be
implemented there some day. That way you won't have the
implementation hassle right now, and your only worry would be fending
of the folks that doesn't like the fact that only internal links can
be fixated. Also, you'd have to comfort Russell Hind :-).
3. is also a good way forward in *my* perspective, but you are
probably going to hit a wall with the real svn developers.
Blerh, what a long text.
Hope my english is understandable.
If not, read it again and try harder to decipher :-D.
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.
I hope we're talking about the same thing (copying the "link" as a "link").
* It might be useful for parallel feature development (eg. you might
want to branch but allow common code updates).
* If you are copying your development trunk to a new place, but you
have to do a couple of things on the old trunk before deleting it, you
can't just use 'svn mv', so you have to make an exact copy of the
trunk folder.
I guess I'd just like there to still be an 'exact copy' feature.
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?
Yes, the property would apply to the directories you wish to contain
your "common code" folders in.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 7 16:28:56 2005