[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: suspected bug report or feature request - tagging a sparse directory

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 14 Jan 2010 11:39:37 -0500

Stas, you are quite right that the messaging here is important, if only to
avoid hurt feelings. Your use-case is a valid one, and we'd all do well not
to discount it. But Subversion simply wasn't designed to accommodate it.
And this isn't even a small "oops we overlooked it" thing. This is a
fundamental difference between the tagging and branching paradigms in CVS
and Subversion -- a difference introduced intentionally when Subversion was
conceived.

I wonder: if you could attach to your tag a view specification that, upon
checkout of the tag, would "kick in" and cause a working copy to be
constructed sparsely as defined in that specification, would your concerns
be alleviated? My line of thinking is this: some work was done to build
out the working copy that serves as the source of your copy. That's work
that might need to be done again someday. It would be nice to preserve that
work a non-destructive fashion: to remember the sparse configuration of
your tree so that it can be "replayed" later, or perhaps by someone else.
Well, what if you could marshal that sparse configuration into the
repository in some fashion so that it could be applied to tags created from
your working copy? What complications or problems does this introduce in
your situation? What problems does it alleviate?

Stas Cherkassky wrote:
> Julian,
>
> thanks you for your reply.
> Your approach may technically work, but, I am afraid, it's not realistic in
> real large project.
>
> The [everything except dirA and dirB] part may be quite complicated for
> large sparse tree.
>
> The second approach (multiple svn cp WC URL) is also cumbersome and requires
> multiple commits.
> It also won't work if some files were already tagged before (you can't svn
> cp over existing file).
>
> Both approaches are not easy to automate (too many cases to consider).
> Just consider, what will happen 2nd time, when user B wants to update the
> tag in his WC. Some files were tagged before, some - not. They may be in
> the same dir, deep inside the tree.
>
> Just compare it to 'cvs tag -R -F tagX myproj'. The -F switch would tag
> untagged files, and move tag on tagged files. Whatever files I have in my
> WC. In one simple command.
>
> You may point our (correctly) that this feature was not requested or was not
> considered important enough - after all it's open source community, and
> developers do what they think is important and interesting to them. And
> this is all correct. Incorrect is to claim that SVN does have the ability.
> Even if it technically does, its absolutely unusable (all IMHO, of course).
> The only real solution that I can see, it to have some switch for 'svn cp'
> that will do exactly what's needed - including override files already under
> the ^/tags/ dir..
>
> thanks,
> Stas
>
>
>
> On Wed, Jan 13, 2010 at 8:00 PM, Julian Foad <julianfoad_at_btopenworld.com>wrote:
>
>> Hi Stas.
>>
>> Your question raises an important issue: "What are the semantics of
>> sparse directories?" You expected "svn copy" to copy just the parts that
>> are present in the WC, whereas in fact it copies the whole logical tree.
>> There is a reason for that, but I think it is not clear how a user
>> should expect each Subversion command to behave.
>>
>> In this email I will just address how it works at the moment and how to
>> achieve the tagging that you wanted. I will start a separate email
>> thread to discuss the semantics of sparse directories.
>>
>>
>> Stas Cherkassky wrote:
>>> I don't want to remove parts of the tree from the repository.
>>> What I want is, effectively, a way to independently mark separate
>>> parts of the tree with the same tag.
>>> (I tried to explain it in my example). I don't see how your method
>>> (using svn rm) does it.
>> I'll explain my method using "svn rm" first, and then the method using
>> "svn copy" with multiple source arguments.
>>
>> You don't exactly want to remove parts from the repository, but one way
>> of thinking about what you want to create in the repository (the tagged
>> data) is a copy of your normal working tree except with some parts
>> removed. A common and flexible way to create a tree in a Subversion
>> repository is to create it in a WC and then commit (or in this case
>> copy) it. That's what my suggestion was for.
>>
>> More precisely,
>>
>> svn rm myproj/[everything except dirA and dirB]
>> svn copy myproj ^/tags/rel_X/
>>
>> And then if you want to restore your WC to how it was, you can revert
>> the parts that are scheduled for deletion:
>>
>> svn revert -R myproj/[everything except dirA and dirB]
>>
>>
>> Another way of thinking about the task is to ask Subversion to copy only
>> the parts you want:
>>
>> $ svn copy --parents myproj/dirA myproj/dirB ^/tags/rel_X/myproj/
>> Committed revision 2.
>>
>> $ svn log -vq -c2
>> ------------------------------------------------------------------
>> r2 | julianfoad | 2010-01-08 10:37:34 +0000 (Fri, 08 Jan 2010)
>> Changed paths:
>> A /tags/rel_X/myproj
>> A /tags/rel_X/myproj/dirA (from /myproj/dirA:1)
>> A /tags/rel_X/myproj/dirB (from /myproj/dirB:1)
>> ------------------------------------------------------------------
>>
>> There is a limitation with this form of the copy command. With a single
>> "svn copy" command, all the specified source objects (dirA and dirB in
>> this case) are created as direct children of the target directory. There
>> is no way to extend that example to make myproj/dirC/foo go to
>> ^/tags/rel_X/myproj/dirC/foo at the same time as copying dirA and dirB.
>> However, you can extend a tag by making a further commit to it with a
>> second copy command, unless committing to a tag is disabled in your
>> repository. So you could do:
>>
>> $ svn mkdir ^/tags/rel_X/myproj -m "New tag. Incomplete."
>> $ svn copy dirA ^/tags/rel_X/myproj/ -m "Incomplete."
>> $ svn copy dirB ^/tags/rel_X/myproj/ -m "Incomplete."
>> $ svn copy --parents dirC/foo ^/tags/rel_X/myproj/dirC/foo
>> -m "Completed tag for rel_X of myproj."
>>
>>
>>> If a tag is a property of a file (like in CVS), it's natural operation :
>>> cvs tag -R dirA -t relX # tags whatever files and versions I have in
>> WC
>>> and then
>>> cvs tag -R dirB -t relX
>>> In the end I have both dirA and dirB tagged with same tag relX.
>> You can certainly do the equivalent thing in Subversion: it is the "svn
>> copy" method that I described above.
>>
>>> If a tag is an object (like in Perforce), and it's property is a list
>>> of files/versions it applies to, it's also easily achievable in very
>>> similar manner - 2nd p4 tag call would just add more files to that
>>> property of the tag object.
>> That is also like the "svn copy" method that I described above.
>>
>>> With SVN's implementation of tags (logical directory in repo), it
>>> would also be possible, had 'svn copy' behave like I suggested.
>> That is true.
>>
>>> IMHO, this way is more intuitive - that's what unix copy command would
>> do.
>>
>> The Unix copy command is not a fair comparison, because a normal Unix
>> directory is not a temporary working representation of the real data
>> stored on the server, and so does not have a way to mark certain files
>> and directories as "excluded from the local working copy". Or, looking
>> at it another way, if you mark some of the directory's children as
>> hidden (by renaming them to start with a dot in Unix), then a copy of
>> the whole directory will still include those hidden items.
>>
>>
>> - Julian
>>
>>
>>
>
>

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2010-01-14 17:40:20 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.