On 5/21/2016 4:53 PM, John P. Rouillard wrote: > In message <C7F6D0C7DBB14445BAF6F56CB651D6A8@Yulichka>, > "Tony Papadimitriou" writes: >> I've had the same wish for a long long time. I would like the FOSSIL BRANCH >> list to show except for the branch name some kind of description. >> Like you mentioned, making the branch name itself long enough would be one >> way to tackle this but it is counter-productive as you would need to type >> the whole thing each time you need to access that branch. >> >> So, I think the simplest way to add this functionality *without* causing >> backward compatibilities or file format changes is to display the first >> commit comment for that particular branch as a description in the BRANCH >> list command. >> >> Although it may not always be the most accurate description for branches >> already created, I think in most cases the first branch commit comment >> represents a pretty good description about what the branch is about, or why >> it had to be created. > > Since tags are really just properties, what about a convention for > adding a branch-description property along sinde the branch=BRANCHNAME > property. > > Thus to add a description, you can run: > > fossil add tag branch-description CHECKIN "This branch implements the > flooze feature, see the BRANCH:flooble wiki page for details." > > where checkin is the revision with the branch= property set.
That's a good thought. The backward-incompatible part of my initial suggestion was due to not knowing where else to store the branch or tag description. I also suggested using the wiki but with drawbacks. The location you suggest makes sense, plus would leverage the existing artifact amendment infrastructure. It's also related to Tony's suggestion in that you both propose storing the description in the first check-in of the branch, but you go a step farther by using a property rather than recycling the comment. How about tags? Put the description in the check-in manifest of the first usage of the tag, I suppose. What if a tag is used multiple times? I'm guessing use the newest which contains the tag-description property. Same goes for branches. Though hopefully there won't be more than one instance per tag or branch. > As an enhancement to the branch command > > fossil branch new BRANCH-NAME BASIS ?OPTIONS? > > add an option "--description" that sets the value for the > branch-description value at branch time. Does anyone use the "branch new" command? It's a relic from the old way of doing branches. I'm not opposed to this suggestion, just asking. Though I would go a step further and add the -description option (maybe renamed -branch-description) to commit so a description can be set at the same time as creating the branch by that method, much more common these days. I suggest wrapping creating/modifying/deleting branch description into new subcommands of branch. Possibly: fossil branch describe BRANCH-NAME ?DESCRIPTION? If DESCRIPTION is omitted, print the description. Otherwise set it, though if DESCRIPTION is empty string, cancel the description property. Do the same for tags: fossil tag describe TAG-NAME ?DESCRIPTION? But I don't think a -tag-description option to commit would work well since there's no sure way to relate which -tag-description option goes with which -tag option, of which there can be multiple. It's a non-issue for branches since only one -branch can be specified. So yeah, don't rename -description to -branch-description; it's unambiguous as it is. On top of all this, I'd still like for the branch and tag list pages to link to wiki pages with the same name as the branch or tag. This provides a place to discuss the branch or tag, to link to tickets and email archives, and to have attachments. -- Andy Goth | <andrew.m.goth/at/gmail/dot/com>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
