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: > Gerhard Fiedler wrote: >> One loosely related feature I'm dreaming about is that the system knows >> what has been merged and excludes anything that has already been merged >> from a future merge (unless an override option is set that advises it >> to merge "literally"), for both unidirectional and bidirectional cases. > > That's not really possible - each revision is dependent on the revision > before it, so for example you have: > > 1.1 Bug 1 > 1.2 Bug 2 > 1.3 Bug 3 > 1.4 Bug 3 > 1.5 Bug 2 > 1.6 Bug 4 > 1.7 Bug 1 > A merge of bug 2 for example must include every revision in between, in > this case implicitly merging bug 3. Let's say you have merged bugs 2 > and 4.. you can record this somewhere (mergepoint history is the wrong > place though* - cvsnt has nowhere to put it.. evs could create a > property with the details in it theoretically). That was my point with bringing this up here. I think the merge points are not enough to document what was actually merged, and as you explained, not even me keeping a log of which bugids I merged is enough. If I merge bugid 2, I get also all enclosed revisions associated with bugid3... Without requesting this, and without knowing it. I think the system should somehow be able to tell me later what it actually did merge. Also, what if at the time of the merge of bugid 2 the work on bugid 3 was not yet completed and in the end depends on a revision "1.8 Bug 3"? The merge of bugid 2 includes then some incomplete and possibly only half working bugid 3. How do you deal with this? The way Arthur describes working with bugids, this must be quite normal. Gerhard