Re: limitations of svn:externals
From: Narayana Prasad <nprasad_at_embeddedinfotech.com>
Date: 2005-11-07 16:31:38 CET
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.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.
same as common code. Sorry for introducing extra terms.I'm not sure what you mean by "dependent modules".
I didnt understand the need to change the property name.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 '.
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.
$ 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.
Molle Bestefich wrote:
--------------------------------------------------------------------- To unsubscribe, e-mail: email@example.com For additional commands, e-mail: firstname.lastname@example.org Received on Mon Nov 7 16:28:56 2005Russell 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.
This is an archived mail posted to the Subversion Dev mailing list.