You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Michael Goetze <mg...@mgoetze.net> on 2006/04/17 20:51:55 UTC
How Subversion drove me to shoot myself in the foot.
Hi,
I just started using Subversion, and am posting this so that hopefully,
some day, it will come with a default behaviour which will prevent what
happened to me happening to someone else.
I decided that it's time to sync my home directories across various
machines, and settled on Subversion as a relatively mature piece of
software likely suited to the purpose. So I read the first 6 chapters of
the Subversion book, and set up a repository.
I added the first few directories with only the slight problems
associated with adding the .ssh directory via svn+ssh. 2 Revisions
without problems. Then I decided to add a directory with a bunch of
LaTeX files in it. So I did an "svn add" on the directory. Well, the it
occured to me that I could trash the .aux and .log files before
committing, as they hardly need to be remembered, so I did that. Oops...
I guess I wasn't supposed to that that. "svn revert" did nothing, since
I hadn't changed any files already managed in the repository. "svn
commit", of course, didn't work either, since it was missing files. "svn
add"ing again? Already under version control! Well, guess I'll have to
use "svn delete"... after all, the book reassured me quite nicely that
"svn delete" never actually deletes anything, it just gets removed from
the next revision. Add it, remove it again, nothing changes, and I can
start over again, right?
However, "svn delete" refused to work... couldn't get a lock. So I did
"svn cleanup" and "svn delete" again... nope, still not working. Well, I
don't need a lock, I just want to get it out of the system. So "svn
--force delete" and then start again.
Oops.
So I just deleted a year's worth of .tex files, permanently. Even though
the Book assured me that "svn delete" never deletes anything
permanently. Right now, I'm pretty angry, mainly at myself, but this
episode hasn't exactly instilled a lot of faith in Subversion's ability
to keep my data safe in me. :(
So please, make "svn commit" do something smart when it notices that
added files aren't there anymore, because this really sucks.
Regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Marc Haisenko <ha...@comdasys.com>.
You should have used "svn revert", as your first guess was :-) But you need to
give it the filename. Try for yourself:
# touch test.file
# svn add test.file
# svn status
A test.file
# rm test.file
! test.file
# svn revert test.file
Reverted 'test.file'
# svn status
#
(the "!" in "svn status" shows a file is missing where it expects one)
--
Marc Haisenko
Comdasys AG
Rüdesheimer Straße 7
D-80686 München
Tel: +49 (0)89 - 548 43 33 0
Fax: +49 (0)89 - 548 43 33 29
e-mail: haisenko@comdasys.com
http://www.comdasys.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Phil Endecott <sp...@chezphil.org>.
Fabian Cenedese <Ce...@indel.ch> wrote:
> svn delete is quite the only command that even has a shell partner
svn mkdir
svn cp
svn mv
--Phil.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by "Paul D. Smith" <ps...@gnu.org>.
In some other tools I've used, rather than remove the working copy it's
simply renamed to something like "foo.c.private" or whatever.
That way you have it there as a private file in your view in case you
still need it or need to recover it, but you don't have to worry about
it being used when it's supposed to be deleted.
--
-------------------------------------------------------------------------------
Paul D. Smith <ps...@gnu.org> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Scott Palmer <sc...@2connected.org>.
On 19-Apr-06, at 1:06 PM, L. Wayne Johnson wrote:
>
> If a file is deleted from the repository it _must_ be removed from the
> working copy. If not you can end up with problems. ...
Sure, but in the case of the original poster, the file was never in
the repository. It was scheduled to be added.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: How Subversion drove me to shoot myself in the foot.
Posted by "L. Wayne Johnson" <wa...@zk.com>.
>> I understand your proposal. But my understanding of add and remove is
>> a bit different. svn delete is quite the only command that even has a
>> shell
>> partner, there's no add, commit, update and stuff on the shell, so I
>> don't
>> see that as a strong argument. svn add just adds an already existing file
>> _to version control_. It doesn't create a new file. For the same reason
>> svn
>> delete should just delete the file _from version control_, without
>> touching
>> the file itself. But as svn delete already exists now we might go your
>> way
>> and introduce a new command to do this action. But anyway I'm only a
>> user, not a developer, so I'll leave the decision to others.
If a file is deleted from the repository it _must_ be removed from the
working copy. If not you can end up with problems. At the very least you
would end up with a bunch of files in your working copy that are no longer
part of the project. At worst you end up with something that works in your
working copy but no where else ...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Fabian Cenedese <Ce...@indel.ch>.
>> The problem in
>> this case is that svn delete (without --force) didn't work in the first place
>> as opposite action to svn add.
>
>I disagree, and I'll repeat my earlier suggestion, which no-one seems to have picked up on yet:
>
>"svn delete" shouldn't be trying to be the opposite of "svn add", it should by trying to be the same as a normal "rm" (or "del"), plus updating the Subversion data as necessary to record what it has done. "svn delete" should *always* delete the file in the working copy, and there should be no doubt in anyone's mind that it is going to do so since a "golden rule" should be that "svn XYZ" does the same as the OS XYZ command plus updating the Subversion data.
>
>Reversing an add is not the same as deleting a file; it could perhaps be "svn subtract", "svn release", or something.
I understand your proposal. But my understanding of add and remove is
a bit different. svn delete is quite the only command that even has a shell
partner, there's no add, commit, update and stuff on the shell, so I don't
see that as a strong argument. svn add just adds an already existing file
_to version control_. It doesn't create a new file. For the same reason svn
delete should just delete the file _from version control_, without touching
the file itself. But as svn delete already exists now we might go your way
and introduce a new command to do this action. But anyway I'm only a
user, not a developer, so I'll leave the decision to others.
bye Fabi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by "brinkleybw@bigfoot.com" <br...@gmail.com>.
I've been following this conversation and decided to share some possible
options from other tools.
In Telelogic's CM Synergy, there were two commands that developers would
improperly interchange with some frequency: add and create. The 'create'
command would create an entry in the database for a new file *and* add a
reference in the user's project (Synergy term for repository); in
contrast, the 'add' command simply added a reference in the user's project
to a file that already existed in the database. There was also an 'unuse'
command that was temporary until the next update.
Following the logic of these terms, the opposites would be 'subtract' to
remove a reference to a file from a project, and 'destroy' to completely
obliterate the file from the database. I think the connotation of the
latter could act as a good deterrent from the accidental shooting of feet.
I'm currently working on a project to implement MKS Source Integrity, and it
appears that you can "drop a member" of a project with the *option* to
remove or retain the working file. History stays around forever (perhaps
unless you are an admin, but I haven't read that far). So, perhaps asking
the user if he would like to delete the working copy in the directory on the
hard drive (explicitness intended) would be prudent.
IMHO, the word 'release' should be reserved for the realm of release
management. i.e. svn may not ever use the term, but at least it would
conflict with the nomenclature of these who do employ the use some release
management scripts, procedures, etc.
Cheers!
-B
On 4/19/06, Duncan Murdoch <mu...@stats.uwo.ca> wrote:
>
> On 4/19/2006 9:39 AM, Phil Endecott wrote:
> > Fabian Cenedese <Ce...@indel.ch> wrote:
> >
> >> The problem in
> >> this case is that svn delete (without --force) didn't work in the first
> place
> >> as opposite action to svn add.
> >
> > I disagree, and I'll repeat my earlier suggestion, which no-one seems to
> have picked up on yet:
> >
> > "svn delete" shouldn't be trying to be the opposite of "svn add", it
> should by trying to be the same as a normal "rm" (or "del"), plus updating
> the Subversion data as necessary to record what it has done. "svn delete"
> should *always* delete the file in the working copy, and there should be no
> doubt in anyone's mind that it is going to do so since a "golden rule"
> should be that "svn XYZ" does the same as the OS XYZ command plus updating
> the Subversion data.
>
> This is how it behaves when the working copy is clean, without
> uncommitted changes. In the current situation with uncommitted changes
> it would result in loss of work, something svn tries really hard to avoid.
>
> I think the current behaviour is correct:
> "svn del" should behave as "rm" when the action is reversible, but
> should complain and require special flags when it would result in
> irreversible changes.
>
> Ryan Schmidt's suggestion to change the complaint sounds like the best
> solution to me:
>
> > "You cannot 'svn delete foo' because foo is not yet in the
> > repository. If you want to revert the scheduled addition of foo, use
> > 'svn revert foo'."
>
> > Reversing an add is not the same as deleting a file; it could perhaps be
> "svn subtract", "svn release", or something.
>
> Or "svn revert", as currently.
>
> Duncan Murdoch
>
> >
> > Thoughts?
> >
> > --Phil.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
-B
Re: How Subversion drove me to shoot myself in the foot.
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 4/19/2006 9:39 AM, Phil Endecott wrote:
> Fabian Cenedese <Ce...@indel.ch> wrote:
>
>> The problem in
>> this case is that svn delete (without --force) didn't work in the first place
>> as opposite action to svn add.
>
> I disagree, and I'll repeat my earlier suggestion, which no-one seems to have picked up on yet:
>
> "svn delete" shouldn't be trying to be the opposite of "svn add", it should by trying to be the same as a normal "rm" (or "del"), plus updating the Subversion data as necessary to record what it has done. "svn delete" should *always* delete the file in the working copy, and there should be no doubt in anyone's mind that it is going to do so since a "golden rule" should be that "svn XYZ" does the same as the OS XYZ command plus updating the Subversion data.
This is how it behaves when the working copy is clean, without
uncommitted changes. In the current situation with uncommitted changes
it would result in loss of work, something svn tries really hard to avoid.
I think the current behaviour is correct:
"svn del" should behave as "rm" when the action is reversible, but
should complain and require special flags when it would result in
irreversible changes.
Ryan Schmidt's suggestion to change the complaint sounds like the best
solution to me:
> "You cannot 'svn delete foo' because foo is not yet in the
> repository. If you want to revert the scheduled addition of foo, use
> 'svn revert foo'."
> Reversing an add is not the same as deleting a file; it could perhaps be "svn subtract", "svn release", or something.
Or "svn revert", as currently.
Duncan Murdoch
>
> Thoughts?
>
> --Phil.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Phil Endecott <sp...@chezphil.org>.
Fabian Cenedese <Ce...@indel.ch> wrote:
> The problem in
> this case is that svn delete (without --force) didn't work in the first place
> as opposite action to svn add.
I disagree, and I'll repeat my earlier suggestion, which no-one seems to have picked up on yet:
"svn delete" shouldn't be trying to be the opposite of "svn add", it should by trying to be the same as a normal "rm" (or "del"), plus updating the Subversion data as necessary to record what it has done. "svn delete" should *always* delete the file in the working copy, and there should be no doubt in anyone's mind that it is going to do so since a "golden rule" should be that "svn XYZ" does the same as the OS XYZ command plus updating the Subversion data.
Reversing an add is not the same as deleting a file; it could perhaps be "svn subtract", "svn release", or something.
Thoughts?
--Phil.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Frank Gruman <fg...@verizon.net>.
>
>>> My preferred way would be the cvs-way to only delete files if given a flag. Like that it's
>>> sure that the user wants to delete the file locally.
>>>
>> What you are describing *is* the current behaviour in this situation (uncommitted changes), and yet apparently not what the OP expected.
>>
>> At some point you have to allow users to shoot themselves in the foot if they try hard enough.
>>
>
> You're right that using --force will delete the file eventually. The problem in
> this case is that svn delete (without --force) didn't work in the first place
> as opposite action to svn add. If that had removed the added status of
> the file "we" wouldn't even have thought about using the --force flag. I
> now know how the current behaviour is, but I can assure you that it
> won't take long until the next poster comes with the same problem.
>
>
Perhaps we are looking at an opportunity to tune the documentation?
I'm not familiar enough with the whole scenario here, but this could be
added as just another example of how to use the various pieces of
Subversion.
I have to admit that I have run into similar situations where I have
added files and then decided that I didn't want to add them. So I
played - I tried delete (without the --force). It didn't work. I did
NOT automatically assume that I needed to add flags to this command. I
read the book again. How dumbed-down does a tool need to be to prevent
.01% of the user base from making mistakes?
As a previous poster pointed out, even if you put an "Are you sure you
want to delete? Y/N" in the middle of this, it is still not going to
keep anyone from shooting themsleves in the foot. The fact that someone
read just enough to see a --force option tells me they at least started
to look at the book or a reference somewhere, but did not understand the
full effects of what this would do.
Regards,
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Fabian Cenedese <Ce...@indel.ch>.
>>>I think it makes more sense for "svn delete" to behave like "svn revert" in the case of added but not committed files, because obviously it is an operation that WILL lose unversioned data.
>>Either that or the mentioned warning to use svn revert instead. My preferred
>>way would be the cvs-way to only delete files if given a flag. Like that it's
>>sure that the user wants to delete the file locally.
>
>What you are describing *is* the current behaviour in this situation (uncommitted changes), and yet apparently not what the OP expected.
>
>At some point you have to allow users to shoot themselves in the foot if they try hard enough.
You're right that using --force will delete the file eventually. The problem in
this case is that svn delete (without --force) didn't work in the first place
as opposite action to svn add. If that had removed the added status of
the file "we" wouldn't even have thought about using the --force flag. I
now know how the current behaviour is, but I can assure you that it
won't take long until the next poster comes with the same problem.
bye Fabi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 4/19/2006 4:44 AM, Fabian Cenedese wrote:
> At 13:27 18.04.2006 -0400, Scott Palmer wrote:
>> On 18-Apr-06, at 12:50 PM, Kevin Galligan wrote:
>>> I think the contention was that 'svn delete' would not delete the actual files from the directory...
>>>
>>> "the book reassured me quite nicely that "svn delete" never actually deletes anything"
>>>
>>> which is, of course, not true...
>>>
>>> "Items specified by PATH are scheduled for deletion upon the next commit. *Files (and directories that have not been committed) are immediately removed from the working copy.* The command will not remove any unversioned or modified items; use the --force switch to override this behavior."
>> Does anyone else think that the strategy of immediately removing (deleting) files that are added but not committed is not consistent with the idea that svn delete will not remove unversioned or modified items?
>
> I also ran into this. If you look in the mail archives you'll find more people
> having had that problem. I recall 2 or 3 alone in the last few weeks.
>
>> I think it makes more sense for "svn delete" to behave like "svn revert" in the case of added but not committed files, because obviously it is an operation that WILL lose unversioned data.
>
> Either that or the mentioned warning to use svn revert instead. My preferred
> way would be the cvs-way to only delete files if given a flag. Like that it's
> sure that the user wants to delete the file locally.
What you are describing *is* the current behaviour in this situation
(uncommitted changes), and yet apparently not what the OP expected.
At some point you have to allow users to shoot themselves in the foot if
they try hard enough.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Fabian Cenedese <Ce...@indel.ch>.
At 13:27 18.04.2006 -0400, Scott Palmer wrote:
>On 18-Apr-06, at 12:50 PM, Kevin Galligan wrote:
>>I think the contention was that 'svn delete' would not delete the actual files from the directory...
>>
>>"the book reassured me quite nicely that "svn delete" never actually deletes anything"
>>
>>which is, of course, not true...
>>
>>"Items specified by PATH are scheduled for deletion upon the next commit. *Files (and directories that have not been committed) are immediately removed from the working copy.* The command will not remove any unversioned or modified items; use the --force switch to override this behavior."
>
>Does anyone else think that the strategy of immediately removing (deleting) files that are added but not committed is not consistent with the idea that svn delete will not remove unversioned or modified items?
I also ran into this. If you look in the mail archives you'll find more people
having had that problem. I recall 2 or 3 alone in the last few weeks.
>I think it makes more sense for "svn delete" to behave like "svn revert" in the case of added but not committed files, because obviously it is an operation that WILL lose unversioned data.
Either that or the mentioned warning to use svn revert instead. My preferred
way would be the cvs-way to only delete files if given a flag. Like that it's
sure that the user wants to delete the file locally.
bye Fabi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Apr 18, 2006, at 19:27, Scott Palmer wrote:
> Does anyone else think that the strategy of immediately removing
> (deleting) files that are added but not committed is not consistent
> with the idea that svn delete will not remove unversioned or
> modified items?
>
> I think it makes more sense for "svn delete" to behave like "svn
> revert" in the case of added but not committed files, because
> obviously it is an operation that WILL lose unversioned data.
No, I think it's a bad idea for "svn delete" to behave one way
sometimes and another way other times. It's better for it always to
behave one way, which is to delete the file in question and to update
the working copy to indicate that the file should be removed from the
repository at the next commit. In the OP's case where the file was
not already in the repository, but was merely scheduled for addition,
a helpful message should be issued which educates the user:
"You cannot 'svn delete foo' because foo is not yet in the
repository. If you want to revert the scheduled addition of foo, use
'svn revert foo'."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Tom Mornini <tm...@infomania.com>.
You can svn revert a deleted file and get it back again.
I like the way it currently works. Makes it very natural
to remove files and 'see' the results.
I believe that you comment about the book saying it didn't
delete anything was referencing the repository, which, of
course, never deletes anything at all, regardless of what
you do.
--
-- Tom Mornini
On Apr 18, 2006, at 1:09 PM, Ron wrote:
> > Does anyone else think that the strategy of immediately removing
> > (deleting) files that are added but not committed is not
> consistent with
> > the idea that svn delete will not remove unversioned or modified
> items?
> >
> > I think it makes more sense for "svn delete" to behave like "svn
> revert"
> > in the case of added but not committed files, because obviously
> it is an
> > operation that WILL lose unversioned data.
>
> Yes, I agree. This drives me a little crazy. When I svn delete a
> file, I would rather it remained, but was just flagged for
> deletion, and only removed when the commit happened.
>
> Although, sometimes it is nice that the file is removed. For
> example, if you remove a file and forget to update the makefile as
> well, at least the makefile fails before you've commit, thinking
> everything is OK.
>
> But all in all, having them delete immediately cause *me* more
> headaches than if they didn't.
>
> There are also some issues with doing svn delete on a directory
> that contains unrevisioned files, in that it just fails. I'd
> rather it deleted it from the repo, but left it on my machine if
> there were unrevisions files in it.
>
> Ron
>
> Scott Palmer wrote:
>> On 18-Apr-06, at 12:50 PM, Kevin Galligan wrote:
>>> I think the contention was that 'svn delete' would not delete the
>>> actual files from the directory...
>>>
>>> "the book reassured me quite nicely that "svn delete" never
>>> actually deletes anything"
>>>
>>> which is, of course, not true...
>>>
>>> "Items specified by /|PATH|/ are scheduled for deletion upon the
>>> next commit. *Files (and directories that have not been
>>> committed) are immediately removed from the working copy.* The
>>> command will not remove any unversioned or modified items; use
>>> the |--force| switch to override this behavior."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Ron <li...@rzweb.com>.
> Does anyone else think that the strategy of immediately removing
> (deleting) files that are added but not committed is not consistent with
> the idea that svn delete will not remove unversioned or modified items?
>
> I think it makes more sense for "svn delete" to behave like "svn revert"
> in the case of added but not committed files, because obviously it is an
> operation that WILL lose unversioned data.
Yes, I agree. This drives me a little crazy. When I svn delete a file,
I would rather it remained, but was just flagged for deletion, and only
removed when the commit happened.
Although, sometimes it is nice that the file is removed. For example,
if you remove a file and forget to update the makefile as well, at least
the makefile fails before you've commit, thinking everything is OK.
But all in all, having them delete immediately cause *me* more headaches
than if they didn't.
There are also some issues with doing svn delete on a directory that
contains unrevisioned files, in that it just fails. I'd rather it
deleted it from the repo, but left it on my machine if there were
unrevisions files in it.
Ron
Scott Palmer wrote:
>
> On 18-Apr-06, at 12:50 PM, Kevin Galligan wrote:
>
>> I think the contention was that 'svn delete' would not delete the
>> actual files from the directory...
>>
>> "the book reassured me quite nicely that "svn delete" never actually
>> deletes anything"
>>
>> which is, of course, not true...
>>
>> "Items specified by /|PATH|/ are scheduled for deletion upon the next
>> commit. *Files (and directories that have not been committed) are
>> immediately removed from the working copy.* The command will not
>> remove any unversioned or modified items; use the |--force| switch to
>> override this behavior."
>>
>
> Does anyone else think that the strategy of immediately removing
> (deleting) files that are added but not committed is not consistent with
> the idea that svn delete will not remove unversioned or modified items?
>
> I think it makes more sense for "svn delete" to behave like "svn revert"
> in the case of added but not committed files, because obviously it is an
> operation that WILL lose unversioned data.
>
> Scott
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Scott Palmer <sc...@2connected.org>.
On 18-Apr-06, at 12:50 PM, Kevin Galligan wrote:
> I think the contention was that 'svn delete' would not delete the
> actual files from the directory...
>
> "the book reassured me quite nicely that "svn delete" never
> actually deletes anything"
>
> which is, of course, not true...
>
> "Items specified by PATH are scheduled for deletion upon the next
> commit. *Files (and directories that have not been committed) are
> immediately removed from the working copy.* The command will not
> remove any unversioned or modified items; use the --force switch to
> override this behavior."
>
Does anyone else think that the strategy of immediately removing
(deleting) files that are added but not committed is not consistent
with the idea that svn delete will not remove unversioned or modified
items?
I think it makes more sense for "svn delete" to behave like "svn
revert" in the case of added but not committed files, because
obviously it is an operation that WILL lose unversioned data.
Scott
Re: How Subversion drove me to shoot myself in the foot.
Posted by Theo Van Dinter <fe...@kluge.net>.
On Tue, Apr 18, 2006 at 12:50:57PM -0400, Kevin Galligan wrote:
> "Items specified by *PATH* are scheduled for deletion upon the next commit.
> *Files (and directories that have not been committed) are immediately
> removed from the working copy.* The command will not remove any unversioned
> or modified items; use the --force switch to override this behavior."
>
> The problem was that at the point 'svn delete' was run, those files were
> versioned.
If they were versioned, they were committed, and therefore the files are in
the repository. Simply doing "svn add" does not make files versioned:
$ ls -la testing
ls: testing: No such file or directory
$ touch testing
$ ls -la testing
-rw-r--r-- 1 felicity fame 0 Apr 18 12:57 testing
$ svn add testing
A testing
$ svn delete testing
svn: Use --force to override this restriction
svn: 'testing' has local modifications
$ ls -la testing
-rw-r--r-- 1 felicity fame 0 Apr 18 12:57 testing
> However, here's a question to the experts in the group. Following these
> steps:
>
> 1) Add files
> 2) 'svn delete' files
> 3) commit
As shown above, the "svn delete" won't actually delete the files until they're
first committed after the add. ie:
1) "svn add" files
2) svn commit
3) "svn delete" files
4) svn commit
> Might there be any history of the added file? Even though its deleted?
> Like it adds the file's data, then deletes it, and there's some way to
> access it. I doubt it, but thought it might be good to check.
Did you commit the files first? If so, a previous revision of the directory
will have the files.
--
Randomly Generated Tagline:
"I think animal testing is a terrible idea; they get all nervous and give
the wrong answers." - Unknown
RE: How Subversion drove me to shoot myself in the foot.
Posted by "L. Wayne Johnson" <wa...@zk.com>.
>"the book reassured me quite nicely that "svn delete" never actually
>deletes anything" which is, of course, not true...
If you read your quote from the book you'll see that subversion behaved
exactly as the book indicated it would:
>The command will not remove any unversioned or modified items;
>use the --force switch to override this behavior.
Note that using the --force flag over-rides the stated behavior
>The problem was that at the point 'svn delete' was run,
>those files were versioned.
From the original post it appears to me that the problem was the the --force
flag was used to override the behavior. I do not believe that any files were
committed:
'So "svn --force delete" and then start again.'
I doubt there is any history since the commit failed because of the missing
files. The svn rever <missing file name> would have fixed the problem. The
'revert' command requires explicit arguments...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Kevin Galligan <ma...@kgalligan.com>.
I think the contention was that 'svn delete' would not delete the actual
files from the directory...
"the book reassured me quite nicely that "svn delete" never actually deletes
anything"
which is, of course, not true...
"Items specified by *PATH* are scheduled for deletion upon the next commit.
*Files (and directories that have not been committed) are immediately
removed from the working copy.* The command will not remove any unversioned
or modified items; use the --force switch to override this behavior."
The problem was that at the point 'svn delete' was run, those files were
versioned.
However, here's a question to the experts in the group. Following these
steps:
1) Add files
2) 'svn delete' files
3) commit
Might there be any history of the added file? Even though its deleted?
Like it adds the file's data, then deletes it, and there's some way to
access it. I doubt it, but thought it might be good to check.
On 4/18/06, Marc Haisenko <ha...@comdasys.com> wrote:
>
> On Monday 17 April 2006 22:51, Michael Goetze wrote:
> > So please, make "svn commit" do something smart when it notices that
> > added files aren't there anymore, because this really sucks.
>
> Problem is: define "smart" in this context. SVN can't do anything about
> missing files, it needs the user to resolve the problem by either
> re-adding
> the file (I mean: copy a real file at the place SVN expects it because you
> told it so with an "svn add" earlier) or by reverting the addition (with
> "svn
> revert").
>
> There's nothing that can be done automatically that would always be
> "right":
> if you commit without the files it would be wrong, as the commit would
> probably be broken (imagine missing source code files that are required by
> the other files you've checked in). That's why SVN just aborts and screams
> for help.
>
> The SVN client *could* ask whether to commit without the files but I feel
> this
> would be a bad idea since too often users would simply type "Y" and then
> complain about the caused problem later. Users normally don't read error
> messages unless they're forced to; to most users questions like "Do you
> want
> me to do XYZ: Y/N" appears as "Do you want this error message to just
> disappear: Y/N", so the error message doesn't really reach the brain when
> the
> error messages disappears by simply pressing "Y". That's a regular problem
> with security and usability.
>
> C'ya,
> Marc
>
> --
> Marc Haisenko
> Comdasys AG
>
> Rüdesheimer Straße 7
> D-80686 München
> Tel: +49 (0)89 - 548 43 33 0
> Fax: +49 (0)89 - 548 43 33 29
> e-mail: haisenko@comdasys.com
> http://www.comdasys.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: How Subversion drove me to shoot myself in the foot.
Posted by Frank Gruman <fg...@verizon.net>.
Russ wrote:
> Correct me if I'm wrong, but doesn't the tourtoisesvn client allow you to commit deletions to the repository?
Yes, it does. When you commit a delete, you are committing that from
this point forward, that file should not be part of your future file
sets. It does not remove past changes.
I think the issue here is that the file was never fully added to the
repository. It was 'marked' for addition, but not yet committed. This
is where the confusion comes from. How to "unmark" a file for addition
to the repository. This poor unfortunate soul ended up deleting files
because of his confusion.
Regards,
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Russ <rs...@istandfor.com>.
Correct me if I'm wrong, but doesn't the tourtoisesvn client allow you to commit deletions to the repository? I know its not command line, and its windows only, but I was under the impression that its just a frontend to the svn command line tool, and doesn't add any extra functionality...
Sent wirelessly via BlackBerry from T-Mobile.
-----Original Message-----
From: Marc Haisenko <ha...@comdasys.com>
Date: Tue, 18 Apr 2006 18:34:57
To:users@subversion.tigris.org
Subject: Re: How Subversion drove me to shoot myself in the foot.
On Monday 17 April 2006 22:51, Michael Goetze wrote:
> So please, make "svn commit" do something smart when it notices that
> added files aren't there anymore, because this really sucks.
Problem is: define "smart" in this context. SVN can't do anything about
missing files, it needs the user to resolve the problem by either re-adding
the file (I mean: copy a real file at the place SVN expects it because you
told it so with an "svn add" earlier) or by reverting the addition (with "svn
revert").
There's nothing that can be done automatically that would always be "right":
if you commit without the files it would be wrong, as the commit would
probably be broken (imagine missing source code files that are required by
the other files you've checked in). That's why SVN just aborts and screams
for help.
The SVN client *could* ask whether to commit without the files but I feel this
would be a bad idea since too often users would simply type "Y" and then
complain about the caused problem later. Users normally don't read error
messages unless they're forced to; to most users questions like "Do you want
me to do XYZ: Y/N" appears as "Do you want this error message to just
disappear: Y/N", so the error message doesn't really reach the brain when the
error messages disappears by simply pressing "Y". That's a regular problem
with security and usability.
C'ya,
Marc
--
Marc Haisenko
Comdasys AG
Rüdesheimer Straße 7
D-80686 München
Tel: +49 (0)89 - 548 43 33 0
Fax: +49 (0)89 - 548 43 33 29
e-mail: haisenko@comdasys.com
http://www.comdasys.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Marc Haisenko <ha...@comdasys.com>.
On Monday 17 April 2006 22:51, Michael Goetze wrote:
> So please, make "svn commit" do something smart when it notices that
> added files aren't there anymore, because this really sucks.
Problem is: define "smart" in this context. SVN can't do anything about
missing files, it needs the user to resolve the problem by either re-adding
the file (I mean: copy a real file at the place SVN expects it because you
told it so with an "svn add" earlier) or by reverting the addition (with "svn
revert").
There's nothing that can be done automatically that would always be "right":
if you commit without the files it would be wrong, as the commit would
probably be broken (imagine missing source code files that are required by
the other files you've checked in). That's why SVN just aborts and screams
for help.
The SVN client *could* ask whether to commit without the files but I feel this
would be a bad idea since too often users would simply type "Y" and then
complain about the caused problem later. Users normally don't read error
messages unless they're forced to; to most users questions like "Do you want
me to do XYZ: Y/N" appears as "Do you want this error message to just
disappear: Y/N", so the error message doesn't really reach the brain when the
error messages disappears by simply pressing "Y". That's a regular problem
with security and usability.
C'ya,
Marc
--
Marc Haisenko
Comdasys AG
Rüdesheimer Straße 7
D-80686 München
Tel: +49 (0)89 - 548 43 33 0
Fax: +49 (0)89 - 548 43 33 29
e-mail: haisenko@comdasys.com
http://www.comdasys.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 4/17/2006 4:51 PM, Michael Goetze wrote:
> However, "svn delete" refused to work... couldn't get a lock. So I did
> "svn cleanup" and "svn delete" again... nope, still not working. Well, I
> don't need a lock, I just want to get it out of the system. So "svn
> --force delete" and then start again.
It's unfortunate that you've lost some files, but you've learned something:
- People don't require a "--force" option unless it is going to do
something that you are probably going to regret. Do a backup first.
Remember Fred Davidson's two laws of computing:
1. Back it up.
2. Do it now.
By the way, if you were using some crappy filesystem like FAT, it would
be relatively easy to recover your deleted files.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by "brinkleybw@bigfoot.com" <br...@gmail.com>.
There is a DOS utility called DriveSpy (www.digitalintelligence.com) to do
this if you are on FAT. I'm not sure what the Linux equiv would be. dd
will get the data, but automatically listing the cluster chains and carving
out the files is a different issue.
Cheers!
-B
On 4/19/06, David L. Crow <cr...@orangeblood.org> wrote:
>
> Michael Goetze wrote:
> > So I just deleted a year's worth of .tex files, permanently.
>
> In most filesystems, the files aren't really deleted, just the pointers
> to them. If you haven't changed your filesystem much since this event
> and you really need the data, you can unmount the filesystem and use
> something like dd to pull the raw data off of the device. Then you can
> use an editor to search for known contents and extract it.
>
> Depending on how fragmented your files are, your work will be much
> harder to reconstruct the full files.
>
> If the data is very important, then it might be worth the effort.
>
> --
> David L. Crow Texas! It's like a
> crow@OrangeBlood.org whole other country.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: How Subversion drove me to shoot myself in the foot.
Posted by "David L. Crow" <cr...@OrangeBlood.org>.
Michael Goetze wrote:
> So I just deleted a year's worth of .tex files, permanently.
In most filesystems, the files aren't really deleted, just the pointers
to them. If you haven't changed your filesystem much since this event
and you really need the data, you can unmount the filesystem and use
something like dd to pull the raw data off of the device. Then you can
use an editor to search for known contents and extract it.
Depending on how fragmented your files are, your work will be much
harder to reconstruct the full files.
If the data is very important, then it might be worth the effort.
--
David L. Crow Texas! It's like a
crow@OrangeBlood.org whole other country.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How Subversion drove me to shoot myself in the foot.
Posted by Kevin Galligan <ma...@kgalligan.com>.
As much as I feel sympathy to losing data, I think you're going to find a
tough crowd here with regards to what happened.
Right before I got to the part about you losing your data I was going to say
that you should just delete the .svn directory and start over.
I'm also surprised that you would make your first attempt on a foreign tool
with all of your data and not at least copy it to a backup first (or make a
zip, etc.).
I know. Done is done.
On 4/18/06, Robert P. J. Day <rp...@mindspring.com> wrote:
>
> On Mon, 17 Apr 2006, Michael Goetze wrote:
>
> > ... So I just deleted a year's worth of .tex files, permanently. ...
>
> and it's subversion's fault that you didn't make backups for a year?
> man, that subversion is one *nasty* piece of software. i'm going to
> be keeping my eye on it *now*.
>
> rday
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: How Subversion drove me to shoot myself in the foot.
Posted by "Robert P. J. Day" <rp...@mindspring.com>.
On Mon, 17 Apr 2006, Michael Goetze wrote:
> ... So I just deleted a year's worth of .tex files, permanently. ...
and it's subversion's fault that you didn't make backups for a year?
man, that subversion is one *nasty* piece of software. i'm going to
be keeping my eye on it *now*.
rday
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: How Subversion drove me to shoot myself in the foot.
Posted by Phil Endecott <sp...@chezphil.org>.
Just one more thought about this unfortunate story:
As far as possible, "SVN xyz" should do the same as the normal OS's "xyz" command while simultaneously updating the SVN metadata. Doing it this way has the advantage of leveraging users' existing understanding of what the commands do. Some SVN commands, including commit and add, fall outside this, but delete could fall inside it: "svn delete" could be reserved for deleting the file from the working copy as "rm" or "del" does, while simultaneously updating the SVN metadata to record the deletion. If this were strictly the case it would never occur to a user that "svn delete" might be the right command to use if you wanted to keep the working copy file.
An additional command could be used to remove a file from SVN while not changing the working copy. "svn release" is similar to a CVS command, while "svn subtract" would have a nice symetry with "svn add".
I'd be interested to know of other cases where "svn xyz" is not equivalent to "xyz; (update SVN metadata)".
--Phil.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: How Subversion drove me to shoot myself in the foot.
Posted by Douglas Pearson <bi...@sunnyhome.org>.
Hey Mike,
That's a terrible story and I think anyone who's ever accidentally deleted a
file that was valuable can feel for you.
I completely agree with your sentiments that SVN is:
a) pretty rough to use at the start for beginners (the whole roots in CVS
thing...)
b) could be much more helpful when things "start going wrong" like in your
add/delete sequence
The problem is that it's basically designed for fairly skilled use by
professional developers and I've found it's quite hard to explain the
concepts and interfaces to others who don't have that background. The good
news is it's a great tool once you figure your way around it, but there's
definitely room for improvement in the interface.
Sorry to hear about your mishap,
Doug
-----Original Message-----
From: Michael Goetze [mailto:mgoetze@mgoetze.net]
Sent: Monday, April 17, 2006 1:52 PM
To: users@subversion.tigris.org
Subject: How Subversion drove me to shoot myself in the foot.
Hi,
I just started using Subversion, and am posting this so that hopefully, some
day, it will come with a default behaviour which will prevent what happened
to me happening to someone else.
I decided that it's time to sync my home directories across various
machines, and settled on Subversion as a relatively mature piece of software
likely suited to the purpose. So I read the first 6 chapters of the
Subversion book, and set up a repository.
I added the first few directories with only the slight problems associated
with adding the .ssh directory via svn+ssh. 2 Revisions without problems.
Then I decided to add a directory with a bunch of LaTeX files in it. So I
did an "svn add" on the directory. Well, the it occured to me that I could
trash the .aux and .log files before committing, as they hardly need to be
remembered, so I did that. Oops...
I guess I wasn't supposed to that that. "svn revert" did nothing, since I
hadn't changed any files already managed in the repository. "svn commit", of
course, didn't work either, since it was missing files. "svn add"ing again?
Already under version control! Well, guess I'll have to use "svn delete"...
after all, the book reassured me quite nicely that "svn delete" never
actually deletes anything, it just gets removed from the next revision. Add
it, remove it again, nothing changes, and I can start over again, right?
However, "svn delete" refused to work... couldn't get a lock. So I did "svn
cleanup" and "svn delete" again... nope, still not working. Well, I don't
need a lock, I just want to get it out of the system. So "svn --force
delete" and then start again.
Oops.
So I just deleted a year's worth of .tex files, permanently. Even though the
Book assured me that "svn delete" never deletes anything permanently. Right
now, I'm pretty angry, mainly at myself, but this episode hasn't exactly
instilled a lot of faith in Subversion's ability to keep my data safe in me.
:(
So please, make "svn commit" do something smart when it notices that added
files aren't there anymore, because this really sucks.
Regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org