Hi Kristis
I understand the example. It clarifies things a lot. Thanks.
The second need I described would also make it possible to:
Have a development branch:
/branches/b_kpm_experiment_with_fixing_707
I suddenly realize that 707 depends on another fix on bug 708 which was
already applied (somewhere, anywhere, it doesn't matter).
I could choose to merge this fix into my branch so I can continue work
on 707. In this case:
Base: /branches/b_kpm_experiment_with_fixing_707
Bug list: 708
and click "create build".
Theres no need to specify a "Target", since we imply that we want the
bug list changes to be applied directly in Base.
It should be possible to implement both capabilities in scmbug_merge,
with little effort. What do you think ?
Yep. But t wold work only in case of the elementary example - what if there
are conflicts? You must support resolving them...
Well I suppose you should check for the common base for the
b_kpm_experiment_with_fixing_707 and the branch/trunk where 708 is in.
Then deny if there are missing version or in more advanced implementations:
- wipe out changes introduced by missing version - would be useful for
builds to
- if not possible (overlapping changes) bring up graphical editor to resolve
it manually..
Granted that would be useful sometimes though
In any case, I made considerable progress setting up a scmbug_merge
utility that collects the information needed from Mantis. Still have to
implement the Bugzilla and RequestTracker backends, but this shouldn't
slow you down:
Ok. When I'm done with linking I'll go on to Mantis frontend.
http://bugzilla.mkgnu.net/show_bug.cgi?id=545
You could start working on scmbug_merge by modifying
src/lib/product/Tools/Merge.pm.in.
Or work on the Mantis frontend and I'll work more on the Merge...
Ok Thx a lot I'll keep you in the loop.
Best regards
Marek
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
