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.
Tony Hoyle 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. That's a feature that probably could make a number of branches unnecessary. Wouldn't the 'goahead' be that all editors remove their edit flag? I think this feature requires an option for commit to not automatically unedit the file, so that it remains edited until it's unedited on purpose. > 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). I think I understood the issue with bidirectional merging now, thanks to Arthur's patience :) And I agree with 'sparingly' and 'short lived'. Gerhard