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.
Gerhard Fiedler wrote: > I do realize this. But sometimes I also want to be able to commit (so that > I have the file history) without having to worry about whether this code > really fully works. For example, when I restructure something, I like to do > a number of commits that may leave the code broken, just to have the > history of what I did. Or work it one section at a time, temporarily > disabling the other, not yet restructured sections of the app. Or when two > work on such a restructuring together... they need to commit to communicate > their changes to each other, but until it's done and tested (not QA tested > but dev tested) it's not for anybody else to use because it just doesn't > work. Eventually (planned but no dev time to implement it at the moment) evs will solve this by checking out different revisions when a file has an active edit on it - basically if you're not in the editors list for the file you get the revision before the edit started.. that way 2 or more people can edit the file using concurrent edits - they get the 'in progress' version and everyone else gets the old version until an editor gives the goahead for this file/changeset to be published. This has the advantage that it stops anyone making incompatible changes in the meantime. I personally don't have anything against using branches for a changeset provided they're used sparingly, and only short lived and against the dev tree (so you don't end up being forced to do bidirectional merging, which is the real problem with too many branches - you end up getting horribly confused about what is actually the latest code and what was merged from an older branch and mistakes are made). Tony