Trouble committing after directory move. "Copy from" entry looks questionable.
I just got XMerge installed. I bought it specifically for this project where we are separating our third-party sources from a high point in our source tree. xMerge seemed to do the right thing in my workspace but my commit is failing. On trunk we have /repo/trunk/src which moved on the branch to /repo/branches/branch/my_new_dir/src we did work to get the branch to build. Meanwhile some developers have added files on trunk /repo/trunk/src/newfile this gets marked as "copied" in the merge view. and the file shows up in /repo/branches/branch/my_new_dir/src/newfile This all looks great BUT the commit fails on the new file and the complaint seems to tbe that the "copy from" directory is incorrect. It is looking to copy from /repo/trunk/my_new_dir/src/newfile but my_new_dir only exists on the branch. Has anyone seen this before? Is there a workaround? Where does the "copy from" info come from? Thanks for any info, Phil
Hello there qlik, There were several bug fixes in the 6.x series of releases (which you must be using with Xmerge). Can you confirm that you are on the most up-to-date version of 6, which is 6.6.13? If not try making sure you are on 6.6.13 and then see if the issue is gone. You can get this here: https://www.wandisco.com/smartsvn/download-archive If you are on 6.6.13 already then let me know, I'll have a go at reproducing this so that I can work out what's wrong.
Hi. Yes, I checked the rev and have 6.6.13 installed. (I just started with the product a couple weeks ago.) I created a new project and the preview of the merge doesn't show any files with a bad "copy from" dir. I hit the merge button to see if things change when I try a full commit. There are thousands of files being moved though so it will take a while before I see a result. I expect it will be the same though as the first iteration was also in a new project with a clean directory. I'll let you know as soon as it completes. I should also note that the moved src directory showed up with a tree conflict. I think I resolved it using the new file structure which removed/moved src from the top of trunk to my_new_dir/src on the branch. What should that resolution be?
I apologize if this is a duplicate post, I thought I posted this reply earlier but don't see it showing up) Hi. Yes, I checked the rev and have 6.6.13 installed. (I just started with the product a couple weeks ago.) I created a new project and the preview of the merge doesn't show any files with a bad "copy from" dir. I hit the merge button to see if things change when I try a full commit. There are thousands of files being moved though so it will take a while before I see a result. I expect it will be the same though as the first iteration was also in a new project with a clean directory. I'll let you know as soon as it completes. I should also note that the top level moved src dir came up with a tree conflict when I started teh commit. I think I resolved it by taking the moved/removed version of the file. (moved from trnk/src to branch/my_new_dir/src)
I tried this again in a new, clean directory and think that the preview showed the correct (/src/dir1) "copy from" directory while the post-merge window shows the incorrect (/my_new_dir/src/dir1) "copy from" directory.
If I "revert" the items in the ui then remove them behind the scenes, I can use the Modify->CopyFromRepository to get teh copy to list correctly and commit. This is a little painful. Is there a way to do tis workaround from a command line(so I can script it)?
In case it makes a difference, the first couple of directories I looked at were merged into on trunk, after my branch was created.
Hi qlik, I've been trying to reproduce what you're seeing here but I've not been able to, I encountered no problems. Would you be able to provide me with your project structure and a step-by-step guide of what you are doing that results in the commit failing?
1-8 of 8
Reply to this discussion
You cannot edit posts or make replies: You should be logged in before you can post.