On Mon, 2004-12-06 at 15:28, Patrick Heinemann wrote:
> Dear all,
>
> I have recently changed the directory layout of our software, e.g.
> $> cd trunk/
> $> svn move IPC/ inter_process_com
> D + IPC
> A + inter_process_com
> $> svn commit
> commited revision 1005
> and so on...
>
Hmm: I don't have an answer for Patrick, but I have seen what might be a
related problem - possibly a bug in "svn move" handling. Here's what
happened to me as best I've been able to work out:
1) I checked out project X
2) I realise that when we'd created the project X repository, we should
have had top-level 'trunk' 'branch' and 'tags' directories. Instead the
component directories of the project itself are at top level. Never mind
- this is SVN, not CVS, so I can move them!
3) I 'mkdir' the missing top-level directories 'trunk', 'branch' and
'tags'.
4) I "svn add" them. (Possible design oversight: why not a "svn mkdir"
command to do that sort of thing as a single operation?)
5) I do some "svn move" commands to shift the project's top-level
directories "Software", "Docs" and "Hardware" into the 'trunk'
directory. (Nuisance misfeature: "svn move" apparently won't take
multiple files/directories and move them all into one directory
destination like Un*x's "mv" or "cp" commands will.)
6) That's got the directory tree looking like I want it!
7) I spend a while further down the tree sorting out a memory leak in
the code.
8) Commit time!
9) I forget whether or not I committed just my memory-leak fix in the
".../Software" subdirectory or whether 'svn' moaned about the directory
tree having been restructured when I tried. Whatever:
10) I go right to the top directory and do a "svn commit" in order to
get the new directory structure into version-control.
11) SVN refuses, pointing out that someone else has committed changes to
the system whilst I've been working on my memory leak.
12) I do an "svn update" to fix that.
13) I repeat my "svn commit" command.
14) DISASTER!! I notice some "D" (deleted) messages amongst the "svn
commit" summary report, then people around the office start complaining
that some of their recently-added files have gone missing after they do
a "svn update" to pick up the new directory structure.
It seems that what happened was that SVN had memorised a specific "move
list" of directories and files that needed moving as a result of my
original "svn move" commands. However, by the time I came to commit the
changes, people had added more files and subdirectories. But my "move
list" wasn't updated to reflect that despite me issuing a "svn update"
command prior to my "svn commit".
So those other users' new files got dropped on the floor. It took the
best part of a day to find what was missing and resurrect them.
Surely, if SVN did create a "move list", it should have limited itself
to just a top-level view, i.e. "move directory .../Software (and all
below it) to .../trunk/Software" and therefore avoid worrying about
whether a specific low-level file .../Software/Gadget6/gui.c had
actually existed at the time I issued the "svn move" order?
Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Dec 7 11:59:31 2004