[evs] Branching on commit, merge documentation

Gerhard Fiedler lists at connectionbrazil.com
Fri Sep 14 01:16:37 BST 2007

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'.


More information about the evs mailing list