Re: How Subversion drove me to shoot myself in the foot.

Would there be anything in the .svn/text-base directory?

I've seen the original, plaintext versions of files at time of initial commit. I'm not quite sure when those get eliminated / changed

________________________________

From: kgalligan@gmail.com [mailto:kgalligan@gmail.com] On Behalf Of Kevin Galligan
Sent: Tuesday, April 18, 2006 12:51 PM
To: users@subversion.tigris.org
Subject: Re: How Subversion drove me to shoot myself in the foot.

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 <haisenko@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