Clarify Merge Behaviour

IronSvelez · Post by **IronSvelez** » Tue Nov 30, 2004 8:33 am

Hi!

One of our developers recently branched some folders/files and made some changes... as his changes progressed, he realized that he needed more files from the main code stream.... so he added the necessary files to the branch folders.

Then he asked me if this was OK... I quickly guessed that this was sort of ok . That since Vault revisions folder changes, then the file(s) in the branch would be considered new files, at merge time the files that conflict in the main code stream would be deleted and the branch versions would be added... the drawback being that history on the file would start over. However... I did not know how changes in the file since the folder was branched would be handled... so with this ambiguity and the "loss" of history on the file, I recomended that he start over with a new branch that included the entire source tree and work from that.

Anyways, what is the definitive behaviour in Vault when this happens? HOw is a filename-conflict-on-merge handled?

And while I'm on the subject of merges.... does vault gracefully handle repeated merges of a branch? And the extension of that: merge branch to main, then main to branch, then branch to main .... ad infinitum.

Thanks,
Steven

ericsink · Post by **ericsink** » Wed Dec 01, 2004 10:57 am

Sorry to be slow on the reply to this. Thanks for reminding us (in your other note) that this one slipped through the cracks somehow.

Merge branches will fuss at you if there is a change in the origin which would conflict with a filename in the target. If the two files happen to be identical, it will stop complaining and assume everything is okay.

Bottom line: This won't hurt too much. The merge branches wizard will draw the situation to your attention, but what you're doing isn't really harmful.

IronSvelez · Post by **IronSvelez** » Wed Dec 01, 2004 11:06 am

Thansk for the response, and no problem on the delay... it wasn't a pressing question.

Steven