I am working on a project where there are 2 other developers. We are using uSync to version control as well as "deploy" changes between our development environments and also to deploy changes to our staging server (only one developer does that).
We have had 2 instances where we have got this error:
Cannot insert duplicate key row in object 'dbo.umbracoNode' with unique index 'IX_umbracoNodeUniqueID'. The duplicate key value is (cf4e2085-258a-45c6-98ae-29e8a4cfc754).
The statement has been terminated.
It's difficult to track what has actually happened, but it seems like on 2 different dev environments, the same (or similar / renamed ?) DocType has been created. Then when dev 2 tries to import the changes from dev 1 via uSync, they get the error. The error has happened both ways round (dev 1 => dev 2 and dev 2 => dev 1).
The solution, at least for me, was to turn off automatic import so that I could get into the CMS, then delete all traces of the troublesome DocType, then turn automatic import on again.
I have used uSync on a few projects now, with different teams / companies and don't remember having any problems.
One thing I did notice is that uSync does not appear to write to the Umbraco Log - so finding the problem was a little bit harder.
The clashes are could happening because of rouge config files hanging around on disk
When a developer renames or deletes a doctype, uSync will move/remove the existing config files from the uSync folder, if you copy over the uSync folder between two locations without also applying deletes /renames you can end up with duplicate doctype folders around the place. (if the folder is source controlled then that should be taking care of that bit)
uSync does try to catch this before adding things but it could be that the ids are clashing before it encounters that on disk
Equally when deletes happen, uSync will clean the folder and log the delete in the uSyncAction.config file (again in usync/data). uSync uses that file to process deletes on import. Deletes happen first so it should clean everything up before an import happens.
two dev creating a doctype with the same alias out of sync could cause an issue but uSync should overcome that by matching on the Alias when it realises the guids don't match.
If you want to increase the logging in usync you can set it to debug in log4net.config file (in /config) add this near the bottom:
I suppose the first thing i would do is make sure the uSync folders are being kept 'clean' on both dev machines, because it sounds like it's extra config files.
are we missing any sort of manual "process"? Dev 1 makes changes which uSync catches and writes to disk (uSync folder). Dev 1 checks all changes, including entire contents of uSync folder into source control.
Dev 2 also does the same thing - either editing different items or possibly editing / creating the same, and checks in.
Source Control (SVN) deals with changes / additions / deletions. Dev 1 and Dev 2 both update their site by restarting IIS (or touching web.config).
Do we need to do a "Full Export" at any time during the process?
And thanks for highlighting the "logging" setting - we might well turn that on for a while!
That sounds right, when you make a change if its a rename uSync should delete the older files.
If you check this in your source control commits, you should be seeing some file deletes/ renames happening inside the uSync folder when a change (that changes the alias of a doctype) is committed.
Most of the time you should never need a Full Export/Import- It's good to do if you think things have gotten out of sync:
Work out which developer/stage/dev environment you consider to be the
master one, and do a full export from it. do a full replacement of the
uSync folders on all other evironments (so delete and replace the
folder) and then do a full import.
We are just trying to investigate where things may have gone wrong - and we suspect that the issue may be with the uSyncActions.config file ... or the lack of it.
I did a check-in recently where I had deleted a DocType. I can see that the uSync definition file(s) for that DocType were checked in as delete actions, but I can't see the uSyncActions.config file being checked in.
So, when does that file get deleted? Does it get created as soon as something is deleted in Umbraco?
the uSyncActions.config file will be created (if it's not already there) when something is deleted
assuming you have ExportOnSave set to true in the uSyncBackOffice.config file.
The file will never get deleted by uSync, even if it ends up empty - uSync will remove delete entries from it, if you later create a new item with the same key/alias (mostly that never happens as the key's are GUIDs but somethings (like dictionary items) are names so can clash.
OK, thanks. I have actually created one properly now, due to some DocType messing I've been doing!! I'll get it source controlled and see how we get on.
Further to this - I think I have discovered when it happens.
Another developer renamed a controller, a DocType (name and alias) and a Template (name and alias).
uSync did not update the uSyncActions.config file, it did delete the files for the old names of each of the above.
Those changes were checked into SVN and I then updated. I loaded the VS project and built the project, which worked OK.
After I restarted my local IIS, I tried to load the umbraco admin and got the error complaining about duplicate keys.
The workaround was to delete the "new name" template folder from uSync, start up Umbraco, manually rename the template (name and alias), then manually recover the "new name" template from SVN (as the content of the template was lost).
I wonder if this is a bug within uSync as it seemed to handle the renaming of the DocType OK?
Getting clashes between developers
I am working on a project where there are 2 other developers. We are using uSync to version control as well as "deploy" changes between our development environments and also to deploy changes to our staging server (only one developer does that).
We have had 2 instances where we have got this error:
It's difficult to track what has actually happened, but it seems like on 2 different dev environments, the same (or similar / renamed ?) DocType has been created. Then when dev 2 tries to import the changes from dev 1 via uSync, they get the error. The error has happened both ways round (dev 1 => dev 2 and dev 2 => dev 1).
The solution, at least for me, was to turn off automatic import so that I could get into the CMS, then delete all traces of the troublesome DocType, then turn automatic import on again.
I have used uSync on a few projects now, with different teams / companies and don't remember having any problems.
One thing I did notice is that uSync does not appear to write to the Umbraco Log - so finding the problem was a little bit harder.
Hi
The clashes are could happening because of rouge config files hanging around on disk
When a developer renames or deletes a doctype, uSync will move/remove the existing config files from the uSync folder, if you copy over the uSync folder between two locations without also applying deletes /renames you can end up with duplicate doctype folders around the place. (if the folder is source controlled then that should be taking care of that bit)
uSync does try to catch this before adding things but it could be that the ids are clashing before it encounters that on disk
Equally when deletes happen, uSync will clean the folder and log the delete in the uSyncAction.config file (again in usync/data). uSync uses that file to process deletes on import. Deletes happen first so it should clean everything up before an import happens.
two dev creating a doctype with the same alias out of sync could cause an issue but uSync should overcome that by matching on the Alias when it realises the guids don't match.
If you want to increase the logging in usync you can set it to debug in log4net.config file (in /config) add this near the bottom:
you will get a lot of logging then :)
I suppose the first thing i would do is make sure the uSync folders are being kept 'clean' on both dev machines, because it sounds like it's extra config files.
Kevin
Hi Kevin,
are we missing any sort of manual "process"? Dev 1 makes changes which uSync catches and writes to disk (uSync folder). Dev 1 checks all changes, including entire contents of uSync folder into source control.
Dev 2 also does the same thing - either editing different items or possibly editing / creating the same, and checks in.
Source Control (SVN) deals with changes / additions / deletions. Dev 1 and Dev 2 both update their site by restarting IIS (or touching web.config).
Do we need to do a "Full Export" at any time during the process?
And thanks for highlighting the "logging" setting - we might well turn that on for a while!
Hi
That sounds right, when you make a change if its a rename uSync should delete the older files.
If you check this in your source control commits, you should be seeing some file deletes/ renames happening inside the uSync folder when a change (that changes the alias of a doctype) is committed.
Most of the time you should never need a Full Export/Import- It's good to do if you think things have gotten out of sync:
We are just trying to investigate where things may have gone wrong - and we suspect that the issue may be with the uSyncActions.config file ... or the lack of it.
I did a check-in recently where I had deleted a DocType. I can see that the uSync definition file(s) for that DocType were checked in as delete actions, but I can't see the uSyncActions.config file being checked in.
So, when does that file get deleted? Does it get created as soon as something is deleted in Umbraco?
Sorry to be a pain Kevin, but it would be great if you could comment on my previous post, regarding the uSyncActions.config file.
Hi
yeah sorry, missed the email notification .
the uSyncActions.config file will be created (if it's not already there) when something is deleted
assuming you have
ExportOnSaveset to true in the uSyncBackOffice.config file.The file will never get deleted by uSync, even if it ends up empty - uSync will remove delete entries from it, if you later create a new item with the same key/alias (mostly that never happens as the key's are GUIDs but somethings (like dictionary items) are names so can clash.
Kevin
Should uSyncActions.config be in the /uSync/Data/ folder? I don't currently have one!?
Can I just create an empty file with that name and check it into SVN?
Hi
it should be in uSync/data.
I think an empty file may cause uSync problems as it's expecting the file to have some formatting, but and 'empty' list like below should be fine.
OK, thanks. I have actually created one properly now, due to some DocType messing I've been doing!! I'll get it source controlled and see how we get on.
Further to this - I think I have discovered when it happens.
Another developer renamed a controller, a DocType (name and alias) and a Template (name and alias).
uSync did not update the uSyncActions.config file, it did delete the files for the old names of each of the above.
Those changes were checked into SVN and I then updated. I loaded the VS project and built the project, which worked OK.
After I restarted my local IIS, I tried to load the umbraco admin and got the error complaining about duplicate keys.
The workaround was to delete the "new name" template folder from uSync, start up Umbraco, manually rename the template (name and alias), then manually recover the "new name" template from SVN (as the content of the template was lost).
I wonder if this is a bug within uSync as it seemed to handle the renaming of the DocType OK?
Hi
yeah i'll have a look, see if there is something in templates.
I think templates might still be looking for aliases on renames - when it should be always looking for the guid values.
I'll need to do some testing see what i find.
Kevin
is working on a reply...