2

We are using Unicorn 2.0.4 to serialize our forms (and other content). These files are then saved into our VSO Git repository. After editing several forms, with similar fields (The forms were originally duplicated) we have noticed that Git managed to mess the .item files, sometimes considering that a file has been renamed when it was actually added in one form and delete from other, pointing the content of the item file to a different item... Has anybody had this sort of issues? and managed to fix them? The side effect of this issues with item files and git is that if the developer committing the file doesn't realize that the actual commit is wrong, the next developer will mess its environment after synching back. I don't think it's related to wffm but we haven't noticed this issue elsewhere.

Following the history of a .item file (one field of a form) we can see:

Commit 1:

+path: /sitecore/system/Modules/Web Forms for Marketers/Website/..../Town

+parent: {78CD1992-7BD2-4AFE-9913-7AAC654B780B} +name: Town

and

Commit 2:

+database: master

+path: /sitecore/system/Modules/Web Forms for Marketers/Website/..../Address4

+parent: {78CD1992-7BD2-4AFE-9913-7AAC654B780B}

name: Address4

1

I would have thought that the git believing that the delete + add was actually a rename should only affect your repo history and nothing more, it shouldn't affect the actual content or location of the files.

As you're using git I would strongly advise you upgrade to Unicorn 3 if you can. It uses custom "Rainbow" serialization that is not only faster (worth the upgrade alone) but was specifically designed to tackle the merging conflicts that .item files face.

There is an upgrade document to assist with this - https://github.com/kamsar/Unicorn/wiki/Upgrading-to-Unicorn-3

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.