Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Gabriel Genellina wrote: > Hello > > Is there a way to do the following?: > I want that *any* time a merge is needed, it's marked as a conflict. > I don't want any automatic merges, no matter how trivial they would be; > I want all merges resolved by the developers. > In other words, if I modify a file in my sandbox and another user > commited a new revision, when I do a cvs update I want it to be flagged > as a conflict, even if the modified lines are far apart. > (You may think it's a bit paranoic -maybe- but we have good reasons to > review all changes before merge) Marking the files as binary will force a conflict. It's not the easiest way to proceed though since there won't be any merging happening. There are better ways of reviewing changes though, assuming that is your intention. Here's a scenario I have used with some newer developers: -- Deny all to commit to HEAD. -- Create developer branch and grant the appropriate developer permissions to it. -- When they are done with their package, they merge from HEAD to their branch to get the latest changes, test, and commit. Then they notify me as the merge-master. -- I have a local sandbox set to HEAD, I merge in their changes from the branch. Then I can do a diff on all the changes they are bringing in. -- Once inspected and approved, the changes are committed to head. If you just want to inspect all the changes, then you could use a mailer program that sends to you a diff of all changes committed. That could also be sent to a maillist / archive for distribution and storage. Hope this helps. -- Glen Starrett