SteveKing wrote:
> Simon Large wrote:
> > 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.
Sorry. I thought I had tried that, but evidently not. Checked it again and
it works exactly as you say. It would be useful if the error message
suggested the corrective action.
> > 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.
If I had done the update correctly in the first place, then no, I would not
need to do any of this. However, assuming I do rename the root folder in the
repository for some reason, then update no longer works because it has lost
its reference to the root folder, so I have to relocate.
If relocate is potentially dangerous, should there be a warning attached?
Even better, can the program check that the URL is valid (assuming the
database is online at the time)? The manual gives no indication that there
may be problems here.
> > 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.
I know the history is still there because I can see it in Repo-browser. I
just tried the "Get All" button and it does indeed follow through the name
change. Out of interest, why is this not the default behaviour?
The "Get All" button does not appear to be documented in the helpfile or
manual (as far as I can see), so I am still not sure exactly what it is
doing - get all what?
> Since you renamed the root folder of your working copy, yes, you will
> get problems because of that.
So would it be a good idea to add a warning dialog to repository folder
rename? The data may be safe, but a mistake like this makes it very
difficult/impossible to access (until 1.1.x arrives). I know renaming may be
a stupid thing to do, but the point of having a nice front end like Tortoise
is that it allows stupid people to use a revision control system.
> 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.
Are you saying that in V1.1.x it will be safe to rename/relocate the root
folder (even if it is un-necessary)?
Simon.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Aug 3 15:50:31 2004