You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Aaron Eppolito <aa...@apple.com> on 2008/04/23 23:26:31 UTC
svn switch to an incorrect branch deletes modified local files
I've posed this warning on Apple's internal svn mailing list and a few
folks have suggested I file it as a bug. It seems policy is to bring
it up in this forum first. I've searched through the bugs and the
~950 matches on "switch" on this list and haven't heard mention of the
problem.
In very short summary, if you inadvertently switch a subdirectory to a
branch/tag/head of the root level, it will DELETE all files in the
subdirectory, INCLUDING locally modified files.
A concrete example:
[myproject/Subdirectory/Files]% svn stat
M file1.cpp
[myproject/Subdirectory/Files]% svn switch https://svnserver/myproject/trunk
D file1.cpp
D file2.cpp
D file3.h
A //// the entire trunk's directory structure...
I understand that what I should have done was this:
[myproject/Subdirectory/Files]% svn switch https://svnserver/myproject/trunk/Subdirectory/Files
That said, svn has enough information to know that switching to a new
working copy rooted in the current directory is not the right thing.
It should have warned, saying something like "This directory does not
correspond to https://svnserver/myproject/trunk".
At the very least, it shouldn't be deleting files with modifications!
Thankfully, I still had these open in an editor so I was able to save
them to a new location, but otherwise, I would have lost all my local
changes.
-Aaron
On Apr 22, 2008, at 11:54 AM, Matt Ackeret wrote:
> write up a bug?
On Apr 22, 2008, at 3:24 PM, Stephen Davis wrote:
> If you switch to something with the same hierarchical layout, then
> svn switch won't touch your modified files. Unfortunately, as you
> discovered, the same does not hold true if the local files do not
> exist in the new hierarchy being laid down.
>
> I hope you filed a ticket with the Subversion team -- I'm sure they
> would treat data loss as an issue worth fixing.
Re: svn switch to an incorrect branch deletes modified local files
Posted by Julian Foad <ju...@btopenworld.com>.
Stefan Sperling wrote:
> On Fri, Apr 25, 2008 at 11:24:12AM +0100, Julian Foad wrote:
>
>>Subcommand 'switch' doesn't accept option '--dry-run'
>
> Oh, sorry! I assumed it did, but I didn't check :/
>
> We should add probably --dry-run to both update and switch on
> the tree-conflicts branch to support this use case. Issue? :)
No, at least not on the tree-conflicts branch. I don't think this is a real
feature request (yet); at the moment we're only speculating that it might be a
useful feature. And it's not trivial - have you seen how the "merge" code tries
to keep track of items that are present on disk but would have been deleted by
now if this were not a dry run?
> So Aaron, I'm afraid that for now, checking for unversioned
> files after a switch/update is the only workaround I know :(
>
>
>>>With tree-conflict detection in place (i.e. not with 1.5, nor
>>>trunk, but our experimental tree-conflicts branch), this will
>>>notify you about conflicts, i.e. you'll see directories flagged
>>>as 'C'. (*lightbulb* Hmmm.... we might actually want to print a
>>>summary of all potential conflicts of any kind after any --dry-run
>>>operation... Cc'ing Julian Foad. Julian, do think this would be
>>>a good idea?)
>>
>>So, in the scenario where you "merge" or "switch" or "update" with
>>"--dry-run" (let's say that were supported), and get thousands of "M"od,
>>"D"el, and "A"dd notifications, and perhaps a few "C"onflicts as well, you
>>want to see at least something like:
>>
>>[[[
>>$ svn <merge|switch|update|whatever> --dry-run ...
>>M a.c
>>M b.c
>>C c.c
>>[...]
>>D foo
>>M bar
>>M baz
>>svn: There were conflicts.
>>]]]
>>
>>(and maybe more detail)?
>
>
> Exactly. Maybe some stats?
>
> $ svn <merge|switch|update|whatever> --dry-run ...
> M a.c
> M b.c
> C c.c
> [...]
> D foo
> M bar
> M baz
> svn: There were conflicts:
> 5 text conflicts
> 1 property conflict
> 2 tree conflicts
>
> Or even print affected paths as well:
>
> svn: There were conflicts:
> 5 text conflicts
> c.c
> xyz
> a/b/c
> parser/parse.c
> security/ssl/ssl.c
> 1 property conflict
> bar
> 2 tree conflicts (showing victims)
> foo
> baz/bay/bax.c
This just duplicates the information already printed by the lines that begin
with "C". We might as well keep the same format.
> This should happen regardless of --dry-run.
Yes, if we're going to repeat the "conflicts" information at the end of the
run, because it's more important than the rest of the output, then I agree we
should do it just the same in real runs as in dry runs.
> I suppose doing this would magnify svn's user-friendliness at
> a non-trivial degree, especially given that with 3 different
> types of conflicts, conflict handling will be getting a lot
> more complicated than it currently is. Note though that interactive
> conflict resolution makes it possible to resolve text (and property?)
> conflicts right during the update process, so depending on how people
> use this feature (and how we make it work with tree conflicts) the
> above example output may be redundant in the non-dry-run case.
Er... I don't really understand what you're saying, but note that we can't
assume that people will resolve all their conflicts interactively.
> Julian, should I open a tree-conflict issue for this, also,
> or append to an existing one? We should consider this when
> we get to the "cleaning up the UI" part.
You could append to the existing issue about tree conflicts UI, a note that it
would be nice to summarise conflicts at the end of the output. I don't see it
as necessary at this stage, just an optional enhancement.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn switch to an incorrect branch deletes modified local files
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Apr 25, 2008 at 11:24:12AM +0100, Julian Foad wrote:
> Stefan Sperling wrote:
>>> This would seem to me to be a good candidate for a --dry-run type of behaviour,
>>> or a verification step before actually attempting to execute the switch.
>>>
>>> An error message of "can't switch - [files/directories list here] would be lost
>>> or damaged" would be very useful.
>>
>> You can (and probably should) run switch with --dry-run first.
>
> Er, no you can't.
>
> Subcommand 'switch' doesn't accept option '--dry-run'
Oh, sorry! I assumed it did, but I didn't check :/
We should add probably --dry-run to both update and switch on
the tree-conflicts branch to support this use case. Issue? :)
So Aaron, I'm afraid that for now, checking for unversioned
files after a switch/update is the only workaround I know :(
>> With tree-conflict detection in place (i.e. not with 1.5, nor
>> trunk, but our experimental tree-conflicts branch), this will
>> notify you about conflicts, i.e. you'll see directories flagged
>> as 'C'. (*lightbulb* Hmmm.... we might actually want to print a
>> summary of all potential conflicts of any kind after any --dry-run
>> operation... Cc'ing Julian Foad. Julian, do think this would be
>> a good idea?)
>
> So, in the scenario where you "merge" or "switch" or "update" with
> "--dry-run" (let's say that were supported), and get thousands of "M"od,
> "D"el, and "A"dd notifications, and perhaps a few "C"onflicts as well, you
> want to see at least something like:
>
> [[[
> $ svn <merge|switch|update|whatever> --dry-run ...
> M a.c
> M b.c
> C c.c
> [...]
> D foo
> M bar
> M baz
> svn: There were conflicts.
> ]]]
>
> (and maybe more detail)?
Exactly. Maybe some stats?
$ svn <merge|switch|update|whatever> --dry-run ...
M a.c
M b.c
C c.c
[...]
D foo
M bar
M baz
svn: There were conflicts:
5 text conflicts
1 property conflict
2 tree conflicts
Or even print affected paths as well:
svn: There were conflicts:
5 text conflicts
c.c
xyz
a/b/c
parser/parse.c
security/ssl/ssl.c
1 property conflict
bar
2 tree conflicts (showing victims)
foo
baz/bay/bax.c
This should happen regardless of --dry-run.
I suppose doing this would magnify svn's user-friendliness at
a non-trivial degree, especially given that with 3 different
types of conflicts, conflict handling will be getting a lot
more complicated than it currently is. Note though that interactive
conflict resolution makes it possible to resolve text (and property?)
conflicts right during the update process, so depending on how people
use this feature (and how we make it work with tree conflicts) the
above example output may be redundant in the non-dry-run case.
Julian, should I open a tree-conflict issue for this, also,
or append to an existing one? We should consider this when
we get to the "cleaning up the UI" part.
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: svn switch to an incorrect branch deletes modified local files
Posted by Julian Foad <ju...@btopenworld.com>.
Stefan Sperling wrote:
>> This would seem to me to be a good candidate for a --dry-run type of behaviour,
>> or a verification step before actually attempting to execute the switch.
>>
>> An error message of "can't switch - [files/directories list here] would be lost
>> or damaged" would be very useful.
>
> You can (and probably should) run switch with --dry-run first.
Er, no you can't.
Subcommand 'switch' doesn't accept option '--dry-run'
> With tree-conflict detection in place (i.e. not with 1.5, nor
> trunk, but our experimental tree-conflicts branch), this will
> notify you about conflicts, i.e. you'll see directories flagged
> as 'C'. (*lightbulb* Hmmm.... we might actually want to print a
> summary of all potential conflicts of any kind after any --dry-run
> operation... Cc'ing Julian Foad. Julian, do think this would be
> a good idea?)
So, in the scenario where you "merge" or "switch" or "update" with "--dry-run"
(let's say that were supported), and get thousands of "M"od, "D"el, and "A"dd
notifications, and perhaps a few "C"onflicts as well, you want to see at least
something like:
[[[
$ svn <merge|switch|update|whatever> --dry-run ...
M a.c
M b.c
C c.c
[...]
D foo
M bar
M baz
svn: There were conflicts.
]]]
(and maybe more detail)?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn switch to an incorrect branch deletes modified local files
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Apr 24, 2008 at 10:22:33AM -0700, Aaron Eppolito wrote:
> Maybe I'll
> sneak in my side question: In cvs you can ask a file for all its
> revisions, regardless of branch. Is there a way to do this in svn?
>
> Foo.cpp r1 -> Foo.cpp r2 -> branch -->
> (head) --> Foo.cpp r3 -> Foo.cpp r5...
> (branch) --> Foo.cpp r4 -> Foo.cpp r6...
>
> [branch/] % svn log Foo.cpp
> r1 | user | date | etc...
> r2 | user | date | etc...
> r4 | user | date | etc...
> r6 | user | date | etc...
>
> It'd be nice to see "[head] r3" and "[head] r5" somehow.
This has been discussed before.
Standard answer:
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=91863
Some newer discussion:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=136229
It's one of Subversion's weak points currently, due to its design.
Some work has been done to fix this a bit, but AFAIK there is no
end result yet.
> Thanks to everyone for the comments. I think the long story short is that
> --dry-run is our friend. That plus your idea of showing *all* conflicts
> seems to be a good one.
Thanks for your feedback!
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: svn switch to an incorrect branch deletes modified local files
Posted by Aaron Eppolito <aa...@apple.com>.
On Apr 24, 2008, at 3:09 AM, Stefan Sperling wrote:
> Well, to tell you what would happen when you do a switch,
> we need to do (or simulate, see below) the switch first.
> We can't magically predict what will happen when you switch
> some arbitrary working copy to some arbitrary directory in
> the repository without doing so and looking at the result.
>
> You can (and probably should) run switch with --dry-run first.
Yeah, I suppose I should get into the habit of this. I wouldn't have
run cvs up -j without doing cvs -n up -j first, so I suppose I
shouldn't try to do the same in svn.
> Making --dry-run mandatory would be needed to get the warnings
> you want by default, but if we did that, people would start
> complaining about performance :(
You're right. Making svn slower == bad!
> Yes, your particular case would trigger tree-conflict detection,
> but isn't the intended use case for it. You supplied a wrong
> argument to switch, that is the core of your problem. And svn should
> be able to cope with that. But how do you expect svn to be able
> to tell you which directory in the repository you want to switch
> to? This may be a weakness in our branching model, but it's arguably
> a trade-off, really -- svn as a tool gives you lots of flexibility,
> but at the price of potentially shooting yourself in the foot
> if the tool isn't used right. It's bit like the C programming
> language in this way :)
I guess. I suppose I prefer cvs's branching model where this sort of
thing can't happen. Everything has advantages and disadvantages.
Maybe I'll sneak in my side question: In cvs you can ask a file for
all its revisions, regardless of branch. Is there a way to do this in
svn?
Foo.cpp r1 -> Foo.cpp r2 -> branch -->
(head) --> Foo.cpp r3 -> Foo.cpp r5...
(branch) --> Foo.cpp r4 -> Foo.cpp r6...
[branch/] % svn log Foo.cpp
r1 | user | date | etc...
r2 | user | date | etc...
r4 | user | date | etc...
r6 | user | date | etc...
It'd be nice to see "[head] r3" and "[head] r5" somehow. In cvs,
since the branching is done in the file, you can see this info. In
svn, any changes made after the copy are no longer linked to the
original. Perhaps some property that says "I came from this file"
would allow something like "svn log --all-copies Foo.cpp".
> Unless you chose to ignore the problem and ran "svn resolved"
> on all items without thinking about the consequences, of course.
> But that would be your own problem, and *you* would have to explain
> this to your co-workers, not us :)
And they should summarily take me out into the parking lot and flog me
if I did that!
Thanks to everyone for the comments. I think the long story short is
that --dry-run is our friend. That plus your idea of showing *all*
conflicts seems to be a good one.
Thanks,
-Aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn switch to an incorrect branch deletes modified local files
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Apr 23, 2008 at 06:07:29PM -0700, Aaron Eppolito wrote:
> Note that the scenario involves a tree conflict. See use case 2:
> http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts/use-cases.txt
> Just replace "update" with "switch" and "move" with "deletion"
> in that description, and you get the situation we're talking about.
>
> Aaron, the corresponding issue in the tracker is:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2282
>
> Yep, given the substitution, that seems right. ;)
> I suppose anything that warns you *before* mangling your WC would be
> infinitely preferred. As I replied to David, a warning ahead of time
> (that would require a --force) would be great.
Well, to tell you what would happen when you do a switch,
we need to do (or simulate, see below) the switch first.
We can't magically predict what will happen when you switch
some arbitrary working copy to some arbitrary directory in
the repository without doing so and looking at the result.
> Donald's comments from
> 2505 echo my sentiment too:
> ------- Additional comments from Donald H Locker Fri Jul 13 04:53:56 -0700
> 2007 -------
>
> This would seem to me to be a good candidate for a --dry-run type of behaviour,
> or a verification step before actually attempting to execute the switch.
>
> An error message of "can't switch - [files/directories list here] would be lost
> or damaged" would be very useful.
You can (and probably should) run switch with --dry-run first.
With tree-conflict detection in place (i.e. not with 1.5, nor
trunk, but our experimental tree-conflicts branch), this will
notify you about conflicts, i.e. you'll see directories flagged
as 'C'. (*lightbulb* Hmmm.... we might actually want to print a
summary of all potential conflicts of any kind after any --dry-run
operation... Cc'ing Julian Foad. Julian, do think this would be
a good idea?)
I suggest that in your work flow, you make it a habit to use
--dry-run for things that you know may cause trouble (such as
whenever you accidentally supply the wrong switch target ;)
Making --dry-run mandatory would be needed to get the warnings
you want by default, but if we did that, people would start
complaining about performance :(
Note that nobody is stopping you from using wrapper scripts
around svn in your software development process that enforce
certain behaviour though.
> As it is, I have to look at all the bits I
> know have changed and figure out how to set them aside/protect them, do the
> switch and restore them. Not so bad with ignored or unversioned artifacts, but
> added and renamed bits are a pain.
>
Well, yes, you will have to look after "all the bits" (we call them
"tree conflict victims" in our design). But you will have to do that
either way. Even if svn said:
"I can't switch, because this threatens <long list of files and dirs>.
Use --force to switch anyway."
...and you used switch --force, you may still have tons of files
dropping out of version control, so you may have to re-add them.
And worse, you may potentially forget about some of them, but
commit anyway, and break your project's tree, and have half the
development team knock on your office door to ask wtf you just did
to the tree and why.
> In general, warning on a conflict after the fact in my particular case
> wouldn't be really helpful. I knew I had seriously messed up when I saw a
> hundred 'D's go by followed by the project starting to check out!
Yes, your particular case would trigger tree-conflict detection,
but isn't the intended use case for it. You supplied a wrong
argument to switch, that is the core of your problem. And svn should
be able to cope with that. But how do you expect svn to be able
to tell you which directory in the repository you want to switch
to? This may be a weakness in our branching model, but it's arguably
a trade-off, really -- svn as a tool gives you lots of flexibility,
but at the price of potentially shooting yourself in the foot
if the tool isn't used right. It's bit like the C programming
language in this way :)
Note that file1.cpp may drop out of version control even if you do
an operation that looks sane at first sight. Usually, you don't
have lot's of 'D's to warn you when you run into this kind of problem.
You saw all the 'D's, got alerted, and *then* noticed that file1.cpp
was suddenly "gone" (unversioned). You sort of hit a tree conflict
by accident, and noticed it only because something else weird was going on.
But such a tree conflict may happen any time someone deletes a file
and you run update on top of that file, which you've locally modified.
Hardly uncommon...
By flagging such things as conflicts, we're making sure that you
*can't* break your project's tree as a result of such an event
and similar events. You simply can't commit any of the affected
items until you've made a concious decision about what to do about
each of them.
Unless you chose to ignore the problem and ran "svn resolved"
on all items without thinking about the consequences, of course.
But that would be your own problem, and *you* would have to explain
this to your co-workers, not us :)
Think about it in terms of a conflict. Just as with text conflicts, we
cannot tell you in advance whether they will happen. The conflict in
your case is not in file content, but in tree structure. Running the
switch on your working copy essentially tells svn "modify this file,
no... wait, delete it at the same time, er, ...no, modify it, no, wait,
delete it..., etc., etc." These are conflicting operations.
Subversion cannot figure out automatically what you want it to do.
It's a similar problem to when you tell svn that line 5 in a file should
be "foo" and line 5 in the same file should be "bar" at the same time
(text conflict).
Does it make sense now?
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: svn switch to an incorrect branch deletes modified local files
Posted by Aaron Eppolito <aa...@apple.com>.
On Apr 23, 2008, at 5:37 PM, Stefan Sperling wrote:
> On Wed, Apr 23, 2008 at 07:51:28PM -0400, Karl Fogel wrote:
>> Aaron Eppolito <aa...@apple.com> writes:
>>> In very short summary, if you inadvertently switch a subdirectory
>>> to a branch/
>>> tag/head of the root level, it will DELETE all files in the
>>> subdirectory,
>>> INCLUDING locally modified files.
>>>
>> Yes, "D file1.cpp" will fly by in the output, but 'file1.cpp' is
>> still
>> there on disk -- it is preserved (as a now-unversioned file)
>> precisely
>> because it was in a modified state when still versioned.
>
> That's the current behaviour, yes.
>
> Note that the scenario involves a tree conflict. See use case 2:
> http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts/use-cases.txt
> Just replace "update" with "switch" and "move" with "deletion"
> in that description, and you get the situation we're talking about.
>
> Aaron, the corresponding issue in the tracker is:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2282
Yep, given the substitution, that seems right. ;)
I suppose anything that warns you *before* mangling your WC would be
infinitely preferred. As I replied to David, a warning ahead of time
(that would require a --force) would be great. Donald's comments from
2505 echo my sentiment too:
------- Additional comments from Donald H Locker Fri Jul 13 04:53:56
-0700 2007 -------
This would seem to me to be a good candidate for a --dry-run type of
behaviour,
or a verification step before actually attempting to execute the
switch.
An error message of "can't switch - [files/directories list here]
would be lost
or damaged" would be very useful. As it is, I have to look at all the
bits I
know have changed and figure out how to set them aside/protect them,
do the
switch and restore them. Not so bad with ignored or unversioned
artifacts, but
added and renamed bits are a pain.
In general, warning on a conflict after the fact in my particular case
wouldn't be really helpful. I knew I had seriously messed up when I
saw a hundred 'D's go by followed by the project starting to check out!
Thanks all,
-Aaron
Re: svn switch to an incorrect branch deletes modified local files
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Apr 23, 2008 at 07:51:28PM -0400, Karl Fogel wrote:
> Aaron Eppolito <aa...@apple.com> writes:
> > I've posed this warning on Apple's internal svn mailing list and a few folks
> > have suggested I file it as a bug. It seems policy is to bring it up in this
> > forum first. I've searched through the bugs and the ~950 matches on "switch"
> > on this list and haven't heard mention of the problem.
> >
> > In very short summary, if you inadvertently switch a subdirectory to a branch/
> > tag/head of the root level, it will DELETE all files in the subdirectory,
> > INCLUDING locally modified files.
> >
> > A concrete example:
> >
> > [myproject/Subdirectory/Files]% svn stat
> > M file1.cpp
> >
> > [myproject/Subdirectory/Files]% svn switch https://svnserver/myproject/trunk
> > D file1.cpp
> > D file2.cpp
> > D file3.h
> > A //// the entire trunk's directory structure...
>
> Yes, "D file1.cpp" will fly by in the output, but 'file1.cpp' is still
> there on disk -- it is preserved (as a now-unversioned file) precisely
> because it was in a modified state when still versioned.
That's the current behaviour, yes.
Note that the scenario involves a tree conflict. See use case 2:
http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts/use-cases.txt
Just replace "update" with "switch" and "move" with "deletion"
in that description, and you get the situation we're talking about.
Aaron, the corresponding issue in the tracker is:
http://subversion.tigris.org/issues/show_bug.cgi?id=2282
We're working on this issue on a branch:
http://svn.collab.net/repos/svn/branches/tree-conflicts/
(But it's not yet the "desired behaviour" described in use-cases.txt
we're implenting.)
With svn from that branch, in your scenario, you should get a conflict
marked on the directory containing the file1.cpp, like this:
[myproject/Subdirectory/Files]% svn switch https://svnserver/myproject/trunk
C . <--- note there
D file1.cpp
D file2.cpp
D file3.h
A //// the entire trunk's directory structure...
Then run 'svn info .' in the same directory, and it'll print a text
explaning the conflict that happened (the UI isn't polished yet).
The output of 'svn info .' should contain something like:
Tree conflict:
The update attempted to delete 'file1.cpp'
(possibly as part of a rename operation).
You have edited 'file1.cpp' locally.
(Note update equals switch -- the UI isn't polished yet :)
You won't be able to commit from that state until you've decided
what to about file1.cpp. You can then mark the conflict as resolved
(currently by running 'svn resolved myproject/Subdirectory/Files',
but this will likely still change a bit).
Note that this branch is *highly* experimental and should not be
used in production. But testing always helps, of course :)
Do you think this new behaviour will help you, once it's there?
Thanks,
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: svn switch to an incorrect branch deletes modified local files
Posted by Aaron Eppolito <aa...@apple.com>.
On Apr 23, 2008, at 5:27 PM, David Glasser wrote:
> On Wed, Apr 23, 2008 at 5:06 PM, Karl Fogel <kf...@red-bean.com>
> wrote:
>> "David Glasser" <gl...@davidglasser.net> writes:
>>>> No, switching to a new working copy rooted in the current
>>>> directory is
>>>> fine -- people do it all the time, and Subversion has no way to
>>>> know
>>>> whether it's right or wrong for your given situation.
>>>
>>> Eh, I deny that it's "fine"... the current working copy code has a
>>> high probability of breaking your wc if you do a weird switch (issue
>>> #2505). This broader issue probably is easier to fix in a wc
>>> rewrite
>>> which constructs a full metadata tree before actually trying to muck
>>> with user files.
>>
>> It may be buggy, but it is an intended feature. I do such switches
>> all
>> the time. In fact they are the majority of switches I perform
>> (because
>> I'm switching from one branch to another, or trunk to/from a branch).
>
> Er, I guess my real position is: "svn switch should be able to do
> arbitrary switches, but in practice it just doesn't work unless you're
> switching between multiple branches at the same level (including trunk
> of course); and when it doesn't work, it's usually unrecoverable".
>
> Though the bad cases I'm referring to are exactly the opposite of what
> you just said... "switching from one branch to another, or trunk
> to/from a branch" are the svn switch cases that I expect to not break.
>
> --dave
I'm nearly certain that they were gone from disk, but it's entirely
possible that in my freakout I overlooked them. Ah, yep, you're right
-- I just tried it and yes, they're still there on disk. All the
unmodifieds are gone, but the modified ones are still there, albeit no
longer versioned.
Furthermore, the switches that you mention (branch -> trunk or vice
versa) are exactly what I was intending to do. What I failed to do
was match directory levels.
Instead of switching from:
https://svn/project/branches/branchname/subdir to
https://svn/project/trunk/subdir
I switched the subdirectory to the root:
https://svn/project/branches/branchname/subdir to
https://svn/project/trunk
resulting in this directory structure:
/project/project/subdir
While I'm sure someone out there has a reason to reroot a new working
copy of a project WITHIN a subdirectory of a working copy of the SAME
project, I'm pretty sure that it's not the 95% case. I guess what I'd
expect is this:
[project/subdir/] % svn switch https://project/trunk
svn: 'https://project/trunk'
is not the same source location as
'https://project/subdir'
use --force to switch anyway
But then again, since project/branch/ looks the same as project/
subdirectory/ to svn, I guess it's just a limitation of the tags/
branches-in-svn-aren't-really thing. Of course, I'd really like to be
able to get info for all the branches of a file like in cvs, but, I
digress...
-Aaron
PS. looks like this is already covered in other bugs so I suppose I
shouldn't file a separate ER. thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn switch to an incorrect branch deletes modified local files
Posted by David Glasser <gl...@davidglasser.net>.
On Wed, Apr 23, 2008 at 5:06 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "David Glasser" <gl...@davidglasser.net> writes:
> >> No, switching to a new working copy rooted in the current directory is
> >> fine -- people do it all the time, and Subversion has no way to know
> >> whether it's right or wrong for your given situation.
> >
> > Eh, I deny that it's "fine"... the current working copy code has a
> > high probability of breaking your wc if you do a weird switch (issue
> > #2505). This broader issue probably is easier to fix in a wc rewrite
> > which constructs a full metadata tree before actually trying to muck
> > with user files.
>
> It may be buggy, but it is an intended feature. I do such switches all
> the time. In fact they are the majority of switches I perform (because
> I'm switching from one branch to another, or trunk to/from a branch).
Er, I guess my real position is: "svn switch should be able to do
arbitrary switches, but in practice it just doesn't work unless you're
switching between multiple branches at the same level (including trunk
of course); and when it doesn't work, it's usually unrecoverable".
Though the bad cases I'm referring to are exactly the opposite of what
you just said... "switching from one branch to another, or trunk
to/from a branch" are the svn switch cases that I expect to not break.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn switch to an incorrect branch deletes modified local files
Posted by David Glasser <gl...@davidglasser.net>.
On Wed, Apr 23, 2008 at 6:50 PM, Karl Fogel <kf...@red-bean.com> wrote:
> The thing that I thought was being claimed as "rare and non-useful" is
> running switch in cwd, especially when cwd is the top of a project
> working copy tree. I rebutted, claiming it is a common case.
Yup, I'm pretty sure that nobody at all is disagreeing with that.
I think I might have put a comment after the wrong paragraph in a
previous reply, leading you to be confused.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn switch to an incorrect branch deletes modified local files
Posted by Karl Fogel <kf...@red-bean.com>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> Karl Fogel <kf...@red-bean.com> writes:
>> It may be buggy, but it is an intended feature. I do such switches all
>> the time. In fact they are the majority of switches I perform (because
>> I'm switching from one branch to another, or trunk to/from a branch).
>
> I think the cost of this feature outweighs any utility.
>
> svn sw ^/branches => OOPS
>
> That sucks even on a sane-sized project. On a big ball of mud?
> CRIPES! So what do poor lusers do after it chugs along for way
> too long? They interrupt it. Hello wc corruption.
>
> I lost count of the number of folks at Lexmark who were burned by this.
I think we're talking about different things here.
The thing that I thought was being claimed as "rare and non-useful" is
running switch in cwd, especially when cwd is the top of a project
working copy tree. I rebutted, claiming it is a common case.
In the case you're talking about above, it doesn't matter whether you
run switch on implied '.' or give it an arg -- the problem is the
mismatch of tree levels (and the quantity of stuffed to be switched to).
I'm all for giving Subversion more smarts as to which switches are good
and which are (probably) mistakes. But that has nothing to do with the
cwd question, AFAICT.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn switch to an incorrect branch deletes modified local files
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Wed, Apr 23, 2008 at 8:47 PM, Eric Gillespie <ep...@pretzelnet.org> wrote:
>> Eric Gillespie <ep...@pretzelnet.org> writes:
>>
>> > svn sw ^/branches => OOPS
>> >
>> > That sucks even on a sane-sized project. On a big ball of mud?
>> > CRIPES! So what do poor lusers do after it chugs along for way
>> > too long? They interrupt it. Hello wc corruption.
>>
>> Glasser just had a good idea: allow the esoteric switch only if
>> the user gives the --ignore-ancestry; otherwise, error out on any
>> switch to a path that doesn't share ancestry.
>
> Mike Pilato (and Glasser) would know better, but didn't we create some
> new API for merge that would make checking this ancestry really easy
> now? I think it would be a good idea too.
>
I was already thinking of using svn_client__get_youngest_common_ancestor()
to make this check. And --ignore-ancestry as a more-appropriately-name
"force" flag sounds great. +1 all over this.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn switch to an incorrect branch deletes modified local files
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Apr 23, 2008 at 8:47 PM, Eric Gillespie <ep...@pretzelnet.org> wrote:
> Eric Gillespie <ep...@pretzelnet.org> writes:
>
> > svn sw ^/branches => OOPS
> >
> > That sucks even on a sane-sized project. On a big ball of mud?
> > CRIPES! So what do poor lusers do after it chugs along for way
> > too long? They interrupt it. Hello wc corruption.
>
> Glasser just had a good idea: allow the esoteric switch only if
> the user gives the --ignore-ancestry; otherwise, error out on any
> switch to a path that doesn't share ancestry.
Mike Pilato (and Glasser) would know better, but didn't we create some
new API for merge that would make checking this ancestry really easy
now? I think it would be a good idea too.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn switch to an incorrect branch deletes modified local files
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> svn sw ^/branches => OOPS
>
> That sucks even on a sane-sized project. On a big ball of mud?
> CRIPES! So what do poor lusers do after it chugs along for way
> too long? They interrupt it. Hello wc corruption.
Glasser just had a good idea: allow the esoteric switch only if
the user gives the --ignore-ancestry; otherwise, error out on any
switch to a path that doesn't share ancestry.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn switch to an incorrect branch deletes modified local files
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Karl Fogel <kf...@red-bean.com> writes:
> It may be buggy, but it is an intended feature. I do such switches all
> the time. In fact they are the majority of switches I perform (because
> I'm switching from one branch to another, or trunk to/from a branch).
I think the cost of this feature outweighs any utility.
svn sw ^/branches => OOPS
That sucks even on a sane-sized project. On a big ball of mud?
CRIPES! So what do poor lusers do after it chugs along for way
too long? They interrupt it. Hello wc corruption.
I lost count of the number of folks at Lexmark who were burned by this.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn switch to an incorrect branch deletes modified local files
Posted by Karl Fogel <kf...@red-bean.com>.
"David Glasser" <gl...@davidglasser.net> writes:
>> No, switching to a new working copy rooted in the current directory is
>> fine -- people do it all the time, and Subversion has no way to know
>> whether it's right or wrong for your given situation.
>
> Eh, I deny that it's "fine"... the current working copy code has a
> high probability of breaking your wc if you do a weird switch (issue
> #2505). This broader issue probably is easier to fix in a wc rewrite
> which constructs a full metadata tree before actually trying to muck
> with user files.
It may be buggy, but it is an intended feature. I do such switches all
the time. In fact they are the majority of switches I perform (because
I'm switching from one branch to another, or trunk to/from a branch).
(And can #2505 only happen when the cwd is the target of the switch?)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn switch to an incorrect branch deletes modified local files
Posted by David Glasser <gl...@davidglasser.net>.
On Wed, Apr 23, 2008 at 4:51 PM, Karl Fogel <kf...@red-bean.com> wrote:
> Aaron Eppolito <aa...@apple.com> writes:
> > I've posed this warning on Apple's internal svn mailing list and a few folks
> > have suggested I file it as a bug. It seems policy is to bring it up in this
> > forum first. I've searched through the bugs and the ~950 matches on "switch"
> > on this list and haven't heard mention of the problem.
> >
> > In very short summary, if you inadvertently switch a subdirectory to a branch/
> > tag/head of the root level, it will DELETE all files in the subdirectory,
> > INCLUDING locally modified files.
> >
> > A concrete example:
> >
> > [myproject/Subdirectory/Files]% svn stat
> > M file1.cpp
> >
> > [myproject/Subdirectory/Files]% svn switch https://svnserver/myproject/trunk
> > D file1.cpp
> > D file2.cpp
> > D file3.h
> > A //// the entire trunk's directory structure...
>
> Yes, "D file1.cpp" will fly by in the output, but 'file1.cpp' is still
> there on disk -- it is preserved (as a now-unversioned file) precisely
> because it was in a modified state when still versioned.
>
>
> > I understand that what I should have done was this:
> > [myproject/Subdirectory/Files]% svn switch https://svnserver/myproject/trunk/
> > Subdirectory/Files
> >
> > That said, svn has enough information to know that switching to a new working
> > copy rooted in the current directory is not the right thing. It should have
> > warned, saying something like "This directory does not correspond to https://
> > svnserver/myproject/trunk".
>
> No, switching to a new working copy rooted in the current directory is
> fine -- people do it all the time, and Subversion has no way to know
> whether it's right or wrong for your given situation.
Eh, I deny that it's "fine"... the current working copy code has a
high probability of breaking your wc if you do a weird switch (issue
#2505). This broader issue probably is easier to fix in a wc rewrite
which constructs a full metadata tree before actually trying to muck
with user files.
Of course, it still shouldn't mess with modified files, and I believe
you that it doesn't.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn switch to an incorrect branch deletes modified local files
Posted by Karl Fogel <kf...@red-bean.com>.
Aaron Eppolito <aa...@apple.com> writes:
> I've posed this warning on Apple's internal svn mailing list and a few folks
> have suggested I file it as a bug. It seems policy is to bring it up in this
> forum first. I've searched through the bugs and the ~950 matches on "switch"
> on this list and haven't heard mention of the problem.
>
> In very short summary, if you inadvertently switch a subdirectory to a branch/
> tag/head of the root level, it will DELETE all files in the subdirectory,
> INCLUDING locally modified files.
>
> A concrete example:
>
> [myproject/Subdirectory/Files]% svn stat
> M file1.cpp
>
> [myproject/Subdirectory/Files]% svn switch https://svnserver/myproject/trunk
> D file1.cpp
> D file2.cpp
> D file3.h
> A //// the entire trunk's directory structure...
Yes, "D file1.cpp" will fly by in the output, but 'file1.cpp' is still
there on disk -- it is preserved (as a now-unversioned file) precisely
because it was in a modified state when still versioned.
> I understand that what I should have done was this:
> [myproject/Subdirectory/Files]% svn switch https://svnserver/myproject/trunk/
> Subdirectory/Files
>
> That said, svn has enough information to know that switching to a new working
> copy rooted in the current directory is not the right thing. It should have
> warned, saying something like "This directory does not correspond to https://
> svnserver/myproject/trunk".
No, switching to a new working copy rooted in the current directory is
fine -- people do it all the time, and Subversion has no way to know
whether it's right or wrong for your given situation.
> At the very least, it shouldn't be deleting files with modifications!
It's not, see above :-).
In case you're in any doubt, here's a reproduction script:
----------------------------------------------------------------------
#!/bin/sh
# Modify the next line to point to your Subversion tree.
SVNDIR=/home/kfogel/src/subversion
SVN=${SVNDIR}/subversion/svn/svn
SVNSERVE=${SVNDIR}/subversion/svnserve/svnserve
SVNADMIN=${SVNDIR}/subversion/svnadmin/svnadmin
URL=file:///`pwd`/repos
rm -rf repos wc *-wc import-me
${SVNADMIN} create repos
echo "### Making a Greek Tree for import..."
mkdir import-me
mkdir import-me/trunk
mkdir import-me/tags
mkdir import-me/branches
mkdir import-me/trunk/A
mkdir import-me/trunk/A/B/
mkdir import-me/trunk/A/C/
mkdir import-me/trunk/A/D/
mkdir import-me/trunk/A/B/E/
mkdir import-me/trunk/A/B/F/
mkdir import-me/trunk/A/D/G/
mkdir import-me/trunk/A/D/H/
echo "This is the file 'iota'." > import-me/trunk/iota
echo "This is the file 'A/mu'." > import-me/trunk/A/mu
echo "This is the file 'A/B/lambda'." > import-me/trunk/A/B/lambda
echo "This is the file 'A/B/E/alpha'." > import-me/trunk/A/B/E/alpha
echo "This is the file 'A/B/E/beta'." > import-me/trunk/A/B/E/beta
echo "This is the file 'A/D/gamma'." > import-me/trunk/A/D/gamma
echo "This is the file 'A/D/G/pi'." > import-me/trunk/A/D/G/pi
echo "This is the file 'A/D/G/rho'." > import-me/trunk/A/D/G/rho
echo "This is the file 'A/D/G/tau'." > import-me/trunk/A/D/G/tau
echo "This is the file 'A/D/H/chi'." > import-me/trunk/A/D/H/chi
echo "This is the file 'A/D/H/omega'." > import-me/trunk/A/D/H/omega
echo "This is the file 'A/D/H/psi'." > import-me/trunk/A/D/H/psi
echo "### Done."
echo ""
echo "### Importing it..."
(cd import-me; ${SVN} import -q -m "Initial import." ${URL})
echo "### Done."
echo ""
${SVN} cp -q -m "Create branch 'mybranch'." \
${URL}/trunk ${URL}/branches/mybranch
${SVN} co -q ${URL}/trunk trunk-wc
${SVN} co -q ${URL}/branches/mybranch branch-wc
cd trunk-wc
${SVN} rm -q iota
${SVN} ci -q -m "Delete iota from trunk."
cd ..
cd branch-wc
echo "A modification to iota on the branch." >> iota
${SVN} switch ${URL}/trunk
cd ..
echo ""
echo "###"
echo "### You just saw 'iota' appear to be deleted. But look,"
echo "### if we run 'cat branch-wc/iota', the file is still,"
echo "### there, although it is no longer versioned:"
echo "###"
echo ""
cat branch-wc/iota
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn switch to an incorrect branch deletes modified local files
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Wed, Apr 23, 2008 at 6:26 PM, Aaron Eppolito <aa...@apple.com> wrote:
> At the very least, it shouldn't be deleting files with modifications!
> Thankfully, I still had these open in an editor so I was able to save them
> to a new location, but otherwise, I would have lost all my local changes.
As others have pointed out over and over, the modified files weren't
actually deleted from disk -- they just became unversioned. As a
point of interest, 'svn up' and 'svn switch' are the exact same
codepath, and thus share this behavior. If your co-worker commits the
deletion of a file which you've locally modified, 'svn up' will
likewise print a big "D file", but won't actually delete the file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org