Hi
Also, how are conflicts going to be issued? Since you can ultimately
delay inserting a bug, for lets say 10 release builds, then the base
files that you initially used to start working on a bug might not be
usable...? (Sorry if my question isn't too clear, I'll try to think of
a situation)...
No, it's a good point. You would have to produce the diffs between
--base-branch and your bug, and then attempt to apply them. If there are
conflicts (so some "patch --dry-run p0 < produced_diffs.patch" command
fails) this will "have to be handled". Perhaps leave the diffs around
for the user to manually inspect and resolve. In any case, the process
would have to stop and the user must manually help. Marek perhaps has
been thinking this some more.
Yep - do autodiff and enforce the user to manually resolve conflicts in
'tags' directory. I have not seen a build process without compiling the
labeled code
There should a warning for unresolved conflicts and a list of auto resolved
conflicts as merging tools are sometimes too smart.
Anyway I think with this strategy we can get with delta subversion almost
all the change-sets, stream based SCMs like McCabe truetrack & truechange or
rational are proud of. The only con would be the weaker auto conflict
resolution in case of overlapping changes.
My actual real life name is Homer Sampson (changed it officially) so
don't think I didn't provide my real name!
Homer
Nice to meet you Homer
Best regards
Marek
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
