Hi,
maybe I'm dense or something (or overlooked an option), so I'm happy if told so
;-)
I'm doing some directory restructuring, and moving directory entire hierarchies
around.
The rest of this (rather lengthy) post is a transcript of all the things that I
did, the error messages and irritations that I encountered along the way, and
some general comments.
Please take this more as a data point about the irritations that somebody with
a CVS background would encounter; some of the things that look like bugs to me
may simply be misinterpretations on my side.
In Windows Explorer, the moved directory gets displayed as deleted in the
original location and as added in the new location. (This is a buglet IMHO: the
directory should simply be removed in the original place, and listed as changed
in the new place. I'm not sure whether it's feasible to fix this, or whether
it's desirable in the first place ;-) )
Anyway, nothing to report until here, but when I try to commit the change, TSVN
seems to act on the assumption that there's really a deletion going on:
First I get a full list of all files and directories to commit deletion.
E.g. when I move .../framework/foo to .../foo, TSVN lists not just
.../framework/foo as "confirm for deletion", but also all the subdirectories
and files therein.
This strikes me as outright wrong, at least on the UI level: I don't care about
the stuff inside the directory, and in fact I shouldn't, and I shouldn't be
able to accidentally leave some of these deletions uncommitted because all of
these files will be present in the new directory anyway.
Second, this presentation is unnerving me quite a bit: if TSVN is really
reporting a move as a delete&create to the repository, will the repository keep
the history? (I sincerely hope it will, and those "Added+" markers seem to
indicate that "something special" is happening, but it's still making me
slightly nervous...)
Third, I get only the .../foo directory as "confirm commit to add". No
subdirectories.
Now while this is actually what I'd like to see, it seems to be inconsistent
with the deletion confirmations, which is making me nervous. (When I look into
the .../foo directory, I find that all subdirectories and files are marked with
a green checkmark, which is somewhat reassuring.)
Fourth, when I select all the deletions and the addition, I get this error
message: "Cannot non-recursively commit a directory deletion".
Now that's quite beside the point, since a recursive delete is exactly what I
want. (Well, actually a recursive move, as detailed above.)
The solution seems to first commit the addition, then the deletion. (I don't
even want to imagine what this means for the version histories... SVN should be
able to handle that, but it will now think it has to handle forked histories,
which is a less well-trodden code path in SVN than the standard case. Ah well,
*somebody* has to be the guinea pig (and I suspect I'm paranoid here anyway).
What I don't like here is that I'm splitting up a transaction. One of the
highlights of SVN is transactioned updates, and being forced to split an update
in two breaks that property. (Or, put another way, I now have a revision in SVN
that's inconsistent.)
Anyway. Committing got me this error message:
Commit succeeded, but other errors follow:
Error bumping revisions post-commit (details follow):
Working copy 'foo/last-subdirectory' is missing or not locked
Uh... anybody got an idea what he's talking about? The directory is still
present locally, so no real harm done, but now I have to unwedge the repository
(something that I have always been able to do, but not all co-workers on the
project are able to do that, which has been hurting acceptance).
Well, next step: to an Update, just in case.
And what I get is my worst nightmare:
Working copy path foo/last-subdirectory' does not exist in repository.
At that point, I switched to bug-hunting mode and simply deleted whatever TSVN
reported as missing in the directory. Turned out that not just that directory
was missing, but everything in the subdirectory, too. The bad thing here is
that I needed a separate update for every single subdirectory and file that was
in .../foo. That's bad - from the first error message, I can't tell whether the
problem is with the reported directory or with all filesystem objects in
.../foo.
Next step in this odyssey: revert the changes.
Er... now the Revert dialog tells me
subdir1 missing+
last-subdirectory missing+
file1 missing+
file2 missing+
I'm confused.
I don't know what that + sign means (except that it's not the normal case -
well, I knew that, I had these directories deleted manually without telling SVN
about it, right?)
Well, to avoid these problems, I simply revert the deletions (thanks goodness
that Windows has a paper bin from which things can be recovered, even Ctrl-Z to
undo the last filesystem changes worked in this case).
However, what happens now is that I get a green checkmark on the .../foo
directory. So no SVN Revert possible anyway. Hopefully SVN Reverting the
deletion will work - I have the Deletion half of a Move, and that's actually an
inconsistent state.
With some dread, I do a Revert on the .../framework/foo directory - phew, it
works.
Now I'm trying to get back to a clean state with .../foo, which means an SVN
Delete.
Urk, it's still complaining about the directory.
Well, delete the stuff inside and to an Update.
Hrm. I get the files restored - hey, they were reported missing+, why are they
now popping out of nowhere?...
... but it doesn't create the directories, it's back to reporting "working copy
path 'foo/last-directory' doesn't exist in repository".
Hey, SVN, I'm doing an *Update* forchrissake, which means "whatever is
happening with the working copy, simply make it match the repository"!!! I'm
glad you'd carp if you'd be overwriting a local change along the way, and I
really, really appreciate this facility, but why am I getting ERROR MESSAGES???
My worst nightmare has come true: my mental model has started to deviate from
the real thing, and there's no clear path back to a consistent state.
I have to revert to mindless experimentation and frobbing until I don't get any
more error messages... yuck.
OK. First emergency attempt: delete the entire .../foo directory and do an
update of the base directory (the thing I've been typing as .../ here).
... I'm hitting lucky. It's simply restoring all the files that were supposed
to be moved. I.e. I now have
subdir1
last-subdirectory
file1
file2
and all the files in the subdirectories, too. In other words, TSVN was
inconsistent with SVN and was unable to synchronize properly (for whatever
reasons), but removing .../foo and its .svn file made TSVN reget the
directory's state from SVN and all was well.
Phew. I sure acquired some more grey hairs now.
Now back to the source directory, .../framework/foo. This one still has to be
deleted.
Mark it with SVN Delete, then right-click it and SVN Commit.
Um... why is it reporting
foo
subdir1
subdir1/... (lots of files with that prefix)
file1
file2
last-directory
Now the order is slightly perplexing (probably the order in which the files
were created, something sorted would be better).
But this is a display bug: it's saying "foo" and "subdir1" as if they were on
the same directory level. (Actually it was getting me a few additional grey
hairs initially, because there is a .../foo, a .../subdir1, and a
.../foo/subdir1 - I initially thought SVN was about to remove .../subdir1. Then
I noticed that the sub-subdirectories and files where still those of
.../foo/subdir1, so it's trying to to the Right Thing, just reporting in a
misleading way. Phew.)
Now clicking OK... and no "Cannot non-recursively commit a directory deletion".
Phew.
I assume it worked because I was right-clicking the SVN Commit on the directory
to be deleted itself. Now that's all well with a directory deletion that's a
transaction in itself, but some directory deletions are just one part of a
transaction, so I think this particular attempt at preventing people from doing
something stupid isn't all that helpful for everybody.
<End of descriptive section>
<Start of proposals section>
1) I think the above transcript shows a lot of places in TSVN that could be
improved. I counted at least one inconsistency with SVN, and several display
problems that led to irritations. I'd like to see these addressed, but I'm
unable to clearly pinpoint the irritations to concrete workings in TSVN -
mostly because I have very little knowledge about the way that TSVN and SVN
work.
Somebody needs to go through the above transcript and identify where exactly
the assumptions in TSVN's coding need to be updated.
I think the best single remedy against the kind of irritation I have been
encountering would be being a bit more explanatory than just giving a + sign.
If it said "missing in working copy, present in the repository" instead of
"missing+", newbies like myself would feel a *lot* more comfortable, and we'd
see more immediately what needed to be done.
2) I can see that TSVN (or maybe SVN - the error message doesn't tell which) is
trying to be helpful by not allowing "dangerous" operations deep inside a
directory hierarchy. (Or is it SVN that does it? The error message doesn't tell
me which of both is reporting the "Cannot non-recursively commit a directory
deletion" error.)
However, at least situations that involve directory moves, this policy is
inappropriate.
Also, I don't think that it's really helping much. There might be deletions of
absolutely important databases deep inside the directory, and there's no way
that SVN could know which files are important and which aren't.
More importantly, even if an entire directory hierarchy is deleted, it can
always be restored. The only thing that makes this difficult is that deleted
directories aren't visible in the hierarchy - but preventing directory
deletions doesn't fix *that* problem anyway, we get deleted directories all the
time. (It might be a good idea to have an "Update with Deletions" option that
recreates all the delete files, with their last names, as hidden files. Maybe
deleted file "foo" should be restored as ".1.foo", with the Hidden attribute in
Windows so they display with dimmed icons, and appropriate context menu
entries. That way, even deleted mega directories can easily be resurrected.)
In particular, I think that handling directory deletion like just any other
operation is going to simplify some code.
<End of proposals section>
Please CC responses to mailto:jo@durchholz.org, I'm not on the mailing list.
Regards,
Jo
(who's slowly getting off his adrenaline rush... ;-) )
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Jul 1 08:09:53 2006