Move /rename detection blocked by some internal error.

[Gerard Murphy]

Hi,

 

I'm using Plastic version 5.0.43.483 - Hawaii, running on Windows 7 under Virtual Box. The repository and workspace are located on my C: drive, not a network share.

 

I'm seeing a bug where I try to do a search for missed file moves in the Pending Changes view. The search dialog finds the correct match, but I can't accept it - see the screenshot attached below, it's self-explanatory.

 

I have 'filestypes.conf' set up to allow F# files to be eligible for move / rename detection, and that works when I do an initial import from Git.

 

Note that Plastic has managed to find and automatically accept one of the renames all by itself, so the underlying functionality is definitely working.

 

I'm going to try shelving these changes and reapplying, just in case there is some temporary glitch: if that solves the problem, I'll post an update...

 

(NOTE: I have the option to show moved / renamed files switched on - this bug occurs regardless of whether I limit the detection to files with the same suffix or not.)

 

 

Regards,

 

Gerard

[Gerard Murphy]

Update: I tried redoing the set of changes from scratch, and this time it worked fine - so why did I see the original problem?

 

After some experimentation, I can reproduce the original problem:-

 

1. Do a rename and make some simple changes - Plastic will detect and accept the file rename to start with. 

 

2. If I then make some more changes without committing the modified changeset from #1 *and rename again*, this then breaks Plastic.

 

3. If I undo the overall file rename from both #1 and #2 but keep the changed and renamed file and redo the file rename by deleting the undone original(!), then again Plastic will start to accept the rename with the final set of changes. There may be other ways of reproducing this too - I'm not sure if this was what I did originally.

[calbzam]

Hi, Thanks for reporting. I will try to reproduce the scenario.

 

Regards,

Carlos