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 14:21:39 2005