Hi,
Nathaniel Smith wrote:
Or just pick whichever single parent is the closest match, and write
out the tag as a child of that.
That would mean adding an artificial patch (from that closest match to
the tag revision you need) and an artificial revision (the one which you
are tagging). To me that seems much worse than adding multiple
artificial merge revisions, because those can easily be filtered away by
log output and such.
Not to mention incremental imports...
Mapping the exact CVS ancestry for
the files in tag revisions into monotone is really far from being a
high priority part of cvs conversions...
Not highest priority, but simple enough to achieve on the way.
and honestly making tag
revisions octopus merges won't really preserve the file history in any
meaningful way anyway.
Why not? 'mtn log' and 'mtn annotate' certainly lead to better results,
than with a 'closest parent' approach.
I'd say just put some metadata in
(cvs:revision attrs, or whatever) and leave it at that.
That should be done anyway. But those things don't turn up in logs or
annotations...
I think we've discussed that before. Why are you insisting on a crippled
approach?
Regards
Markus
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
