On Mon, Aug 19, 2013 at 4:36 PM, Jan Nijtmans <[email protected]>wrote:
> <http://localhost:8080/artifact/daa8eb95e4b13169?ln=636> > my box is undergoing a dist upgrade right now, so i can't do much more than read emails (and my browser will die here soon when it gets updated out from under me). But while i was typing, this arrived: http://fossil-scm.org/index.html/artifact/daa8eb95e4b13169?ln=636 that makes a lot of sense to me for a merge-integrate, and with the tag code fresh in my mind, i don't see that as a problem. The control/manifest artifact types already do tag processing in the crosslink step, so there's no code change there :). > The only caveat is that this way it is not possible to do > multiple "merge --integrate"'s followed by a single > commit any more. Since that's a bad idea anyway, > I added a special check in merge.c disallowing that. > > This is fully compatible with older fossil versions! > As long as the artifact types are syntactically unambiguous, meaning it's always possible to determine their type based on their card letters (letters only, ignoring the card parameters), i'm happy :). Any ambiguity would potentially open up a big can of worms for both fossil(1) and fossil(3). AFAIK the option of adding new cards is there (and we've got a few letters left ;), provided they can be justified very well and don't come after 'Z' (the parsing of that card is done _first_, so it must remain be at the very end) ;). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
