Simon Large wrote:
> This concerns 2 possibly inter-related problems. And it may be a SubVersion
> feature rather than Tortoise, but here goes ...
>
> I start out with a folder hierarchy who's top level is (perhaps foolishly)
> called 'My Firmware' with a space after 'My'. I can add this, make changes,
> commit, etc just fine. When I want to make a release I try to create a tag
> copy in my tags folder, but the operation fails with message:
> Commit failed (details follow):
> Out of date: '/My Firmware/Tage/Test/Comms/Fifo.c' in transaction '1n'
"Out of date:" means that your working copy is "out-of-date" in relation
to the repository. All you have to do is an update! Nothing more,
nothing less! Just do an update and the tag will work.
> Having gone back and checked that there is no real problem with Fifo.c, I
> suspect that there may be a problem with spaces in filenames, so I go to
There were some problems with spaces in filenames in early versions, but
I haven't heard anything related to spaces in filenames anymore for a
long time. Only the svnserve still has one little issue with it, but
that got fixed in HEAD. Other protocols don't have any problems with
those anymore (AFAIK).
> Repo-Browser and rename 'My Firmware' to 'MyFirmware' - no space after 'My'.
> I relocate my working copy and retry the tag, but now it fails with message:
> Commit failed (details follow):
> File not found: revision '36', path '/MyFirmware/Trunk'
Why did you do a relocate? A simple "update" should have worked!
Also, be _very_ careful with the relocate command: if you pass an
invalid new URL there, you end up with a crippled working copy.
> At this stage I am not too worried. I create a new working folder, checkout
> and now I can tag with no problem, confirming my theory about spaces in
> filenames.
Not quite. As I said, all you had to do was updating. But since a
checkout also means that your working copy is up-to-date with the
repository the tag works. _That's_ the reason why it worked, not the
spaces ;)
> I carry on making a few more update/commits, but then I notice that show log
> indicates a complete loss of history prior to the folder name change, and I
The history is _definitely_ not lost. It may stop on the folder change,
but if you hit the "Get All" button the log will follow that rename.
> cannot update/switch to these earlier revisions either. Now I am worried, so
> I change the name back again. Bad mistake. Now I can't go forward or back.
> Because it is trying to get data from a tree whose name has changed (twice)
> it keeps falling over with error messages about inaccessible earlier
> revisions. It appears that trying to reconstruct data which crosses a name
> change boundary causes problems, even if I know the folder name in the
> revision I want. The repository still shows the full history in
> Repo-browser, so I don't think there is any real data loss. It is just that
> I can't get to it any more from my working folders. Cleanup, relocate, etc
> do not help.
Since you renamed the root folder of your working copy, yes, you will
get problems because of that.
> Fortunately this is not real data as I am only evaluating at the moment.
> However, it illustrates 2 major problems.
>
> Firstly that tags don't work if there is a space in the folder name. I don't
> know if there are other problems when files/folders have spaces in the
> name - this is just the first one I came across.
See above. Not a problem.
> Secondly, changing things in Repo-browser seems a potentially dangerous
> thing to do. Would there have been any way to recover my versioned data had
> it been real? If not, maybe you could make it less easy to perform a
> damaging operation in Repo-browser - there were no warnings at all when I
> renamed. According to the manual, repo-browser is just a different window
> onto the same data, implying that there is no particular danger here, but in
> this instance it was a false assumption.
FYI: in Subversion 1.1.x (will be released in about a month), all
commands are able to "follow the history", i.e. renames won't be a
problem anymore. In 1.0.x, only "log" could follow the history, all
other commands did not.
So the problem with your unecessary rename will go away with the next
release.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Aug 2 21:31:58 2004