On Nov 2, 2007, at 9:11 AM, Bicking, David (HHoldings, IT) wrote:
>> -----Original Message-----
>> From: Steven Bakke [mailto:email@example.com]
>> On Nov 1, 2007, at 3:25 PM, Bicking, David (HHoldings, IT) wrote:
>>>> -----Original Message-----
>>>> From: Miller, Eric [mailto:Eric.Miller@amd.com]
>>>>> I am a bit confused by the question. Are you saying that you have
>>>>> paths as a single working copy, then "switched" C and A to tags
>>>>> elsewhere in the repository, then deleted C from the
>>>> repository? Is
>>>>> "path" a subfolder of trunk and tag1 and tag2 subfolders of tags?
>>>> Yes. This is the working copy:
>>>> path/ => trunk/path
>>>> path/A => tags/tag2/path/A
>>>> path/B => trunk/path/B
>>>> path/C => tags/tag1/path/C
>>>> In a revision after tag1 was created the path trunk/path/C was
>>>> Now I want path/C to be the same as trunk/path/C (deleted) without
>>>> affecting path/A.
>>>> If I did a 'svn sw trunk/path path' then path/C would get deleted,
>>>> but it also forces path/A to the trunk as well, which I need to
>> This is the perfect scenario for tags which are 'labels' rather than
>> cheap copies. It really illustrates how cheap copies really are
>> different from labeling an arbitrary set of revisions. A lot of
>> people would be happy if labels existed such that acrobatics such as
>> decribed above would not be necessary.
> Perhaps, but I still can't wrap my head around why he needs to do
> I can't answer his question, either, because I don't think what he
> is possible. I suspect my problem with this is due to the number of
> years I've been working on Java or DotNet style projects.
> Generally, I
> don't see any value in arbitrarilly switching subprojects around.
> in a more low-level environment, like C, where such rigid
> project/package definitions don't exist, this kind of mixed bag is
> Unfortunately, I have to step back from this problem because I cannot
> offer any constructive ideas. I do want to understand the reason for
> this scenario, though.
I was thinking that I'd like to boil this problem down a bit further.
Let's say I want to take a look at what is in another tag for one of
% cd <work>
% svn switch <tag-URL> <work>/A
(Look at the files and do whatever. No modifications)
Now lets say I want to switch back to trunk, since I'm done looking
at whatever was in that tag.
% svn switch <trunk-URL> <work>/A
When 'A' had been deleted from trunk in the interim, there is no way
to do this. In my opinion, this is a flaw in subversion.
Regardless of whether you understand the reasoning for it, I believe
you should always be able to "undo" a switch successfully. I'm
thinking this is somewhat related to the "depth" issue being dealt
with in 1.5. Once a directory becomes part of the current working
copy, it is impossible to remove it.
Lastly, the common "solution" suggested for cases such as this is to
do a fresh checkout. That's not really a good option in a number of
cases. I should be able to issue a legal series of commands to get
me back where I was considering that I didn't do any local
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Nov 2 15:29:04 2007