Julian,
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.
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.
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.
With SVN's implementation of tags (logical directory in repo), it
would also be possible, had 'svn copy' behave like I suggested.
IMHO, this way is more intuitive - that's what unix copy command would do.
regards,
Stas
On Thu, Jan 7, 2010 at 2:42 PM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> Stas Cherkassky wrote:
> [...]
>> % svn co $SVNROOT/myproj -–depth empty myproj
>> % svn update -–depth infinity myproj/dirA
>>
>> .. modifies it in some way and tries to tag:
>>
>> % svn mkdir $SVNROOT/tags/rel_X
>> % svn copy myproj $SVNROOT/tags/rel_X/ -m “tagging part A of myproj
>> for the next integration”
>>
>> The problem that we see is SVN for some reason also copies dirB under
>> $SVNROOT/branches/rel_X !!
>> % svn ls $SVNROOT/tags/rel_X/myproj
>> dirA
>> dirB <- this should not be there !
>>
>> my SVN version is 1.6.2 (r37639)
>>
>> I was under impression that svn copy WC -> URL should take whatever I
>> have in my WC,
>> and ONLY that, similar to unix copy.
>> The whole point of this mode (WC -> URL) it to remember (tag) any
>> weird combination of versions/components
>> that I've built in my WC. So why copy the rest of the world ?
>
> The idea of the sparse WC is "I know that other stuff exists as part of
> this project tree, but I don't need to see that other stuff right now."
>
> If you want to create a WC that represents your project tree pruned down
> (with parts removed), you have to use the "svn rm" command to do that:
> "svn rm dirB". Otherwise the other stuff is still conceptually "there"
> in terms of the versioned tree.
>
> I don't know if you can currently use "svn rm" on a node that is
> excluded from the WC because of a sparse WC. If not, that would be a
> good feature enhancement to make that possible.
>
>> If
>> that's not a bug but feature, would it be possible
>> to have a switch to copy command that would behave as I described ?
>
> I think the method above is better. There are several ways a node can be
> missing from the WC, and adding a switch (or switches) to the copy
> command to control this behaviour is probably not the best way to design
> the solution. Also "copy" is not the only operation you might want to do
> [1]. It's better to get the WC into the state you want (which as I say
> is not achieved just by making it sparse) and then issue a simple "copy"
> command, rather than use a more complex copy command that has options.
>
> [1] Hmm, but what does "export" from the WC do? Does it go to the repo
> to get the excluded parts?
>
> - Julian
>
>
>
Received on 2010-01-08 01:31:44 CET