[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re[2]: [TSVN] 1.2.2... sad story

From: Flex <flex_at_datecs.bg>
Date: 2005-09-01 22:58:33 CEST

> Your mails keep getting bigger and bigger. And harder to read.
> Can you try to keep your reports small next time? Just keep the
> important information ;)

Lol
I'm trying to give as much details as possible so don't miss some important thing :)
But will try to be shorter next time :)

> Why didn't you create the new folder in the wc, added it and committed
> it from your wc? Doing that via repobrowser just seems a little strange
> to me - but maybe that's just me.

lol u r right :)

>> 4. Selected all files & folders extept the Subproject1 (some were under
>> verison control, some not) and used TSVN move to SubProject1.
>> 5. TSVN complained that some folder had local modifications. This was
>> not true, I had just updated it and all was green so I let it continue.

> TSVN always shows you that error if the move didn't work the first time
> (without the --force option), no matter what error really happened. I
> think I have to change that some time.

Yep, that will be good, then I'll know what it complained in fact since I don't see a reason it'll not pass the first time...

>> 6. Operation failed for some reason around this local modification

> With what error message?

Sorry... :(
Forgot it and I'm too scared to repeat the procedure...

>> 7. I selected manually the remaining files & folders and tsvn moved to
>> the Subproject1

> I don't know why this worked. You can't move a file or folder again
> without having committed first. You should have got an error message
> here and the move shouldn't have worked!

> Subversion only can move files/folders *once*, as you only can rename a
> file/folder once. If you want to move/rename again, you *must* commit
> the first move first. Then you can do the second move.

Well... some of the folders actually got in, so I just moved the rest, for example I was able to move Dir1 and Dir2, but it failed on Dir3, so the second time I moved Dir3 and the rest...?

> But I'm a little concerned that you didn't get an error message.

>> 10. I decided to commit this one but it failed - Project/trunk/COMMON
>> was locked?!

> You can't really move an external folder. You should delete (normal
> delete) the external folder, then update again (the external folder is
> not really part of the working copy - it's just checked out because of
> the svn:externals property).

I did :D
Yep, will be nice if something stops me from doing stupid things...

>> First, the folder has dissapeared from the repository where it was
>> (remeber it was used via svn:externals). Strange - I imported it again

> That's because you moved the external folder - again I'm concerned that
> you didn't get an error message and that the move even worked!

I surely got a couple of "locally modified" error messages in the whole mess but nothing stopped me (after the first try).

>> 15. Tried cleanup, unlock, check for modifications + check repository,
>> checked the settings on that folder in the wc and in the repository -
>> nothing

> 'unlock' doesn't help at all. The 'folder is locked' error message means
> that the folder is locked by the file system or the working copy. It has
> nothing to do with Subversion locks (reserved checkouts). Unfortunately,
> the same word (locked) is used in even more places throughout Subversion
> with different meanings.

Confusing... :)

> Check the properties on Subproject1, and the URL of Subproject1 and
> Subproject1\COMMON.
> What I think happened here:
> Subproject1 contains the svn:externals property for COMMON, but COMMON
> also is part of the Subproject1 folder (*not* as an external, but for
> real). So Subversion tries to update Subproject1 and COMMON, then tries
> to check out COMMON again as an external and fails because the URL's
> don't match - you see the 'locked' error message.

right... absolutely this is the case somehow after these moves it got as a part of the Subproject1

What about the Project/trunk/CORE/Icons folder with the versioned files in but not present in the repository? I can easily delete it from the rep and delete the '.svn' folder, then insert again, but do you want me to check something on it before I wipe it out? It is very strange situation...
Received on Thu Sep 1 22:01:15 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.