Re: [fossil-users] Versions & manifests
On 04/01/16 08:18, Steve Stefanovich wrote:
> Would it be too difficult to put the branch tag (i.e the tag with asterisk
> from 'fossil br li' output) in the first line of manifest.tags?
It probably wouldn't, but I've been trying to keep the code agnostic
with regards to being used in a checkout or not. The "current branch
tag" is not applicable when generating archives from the web ui, for
instance. Rather than having the build system expect the version tag to
be on the top, I'd argue it's better to use a naming convention which
makes it easily and uniquely grep:able. (This is of course a problem if
a project/organization has an long-established naming policy which isn't
compatible with this idea).
> We use the combination of uuid and branch tag for versioning.
For my test-project, this is what I do in my amalgamation script:
---
uuid = ""
with open("manifest.uuid", "r") as f:
uuid = f.readline().strip()
ver = "99.99.99"
prg = re.compile("ctlib-((\d+).(\d+).(\d+))")
with open("manifest.tags", "r") as f:
for line in f:
res = prg.match(line)
if res:
ver = res.group(1)
break
---
Generated source header:
---
/*
* Amalgamated public ctlib interface header
* Generated on 2016-01-04 at 16:46:45 UTC
* Based off ctlib-0.8.1, checkout a6a61b0f239bc1f8a458a92bde37160bf6639b4f
*/
---
In our case, there will never be a DAG node which will have more than
one release tag, so there will only ever be exactly one hit for release
versions, and zero hits otherwise.
Is this not sufficient for your needs? I'm not completely opposed to
implementing what you're asking for, but if it can already be done
without adding a "within a checkout" special case, I would prefer to
leave it as it is.
--
Kind Regards,
Jan
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Adding attachments via the command line
On 04/01/2016 14:07, John P. Rouillard wrote: In message <568a7b26.7020...@zombi.eclipse.co.uk>, David Vines writes: On 04/01/2016 12:21, Stephan Beal wrote: fossil att[achment] add ... If it's a subcommand of "wiki" then the ability to use any unique short form of it doesn't come for free (that only works for top-level commands). I was unaware of this capability, and it makes sense to me. The length of the command didn't worry me [...] but I can see the advantage and I'm very happy to make this change. Would this change also make sense for (a future extension) of fossil att[chment] --ticket , to add an attachment to a ticket? It does, though adding an "attachment" subcommand to ticket would have been the corresponding variate. Would adding the capability be of use to you? It's a relatively trivial extension to an attachment command version David ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Adding attachments via the command line
On 04/01/2016 12:21, Stephan Beal wrote: fossil att[achment] add ... If it's a subcommand of "wiki" then the ability to use any unique short form of it doesn't come for free (that only works for top-level commands). :-? I was unaware of this capability, and it makes sense to me. The length of the command didn't worry me since my main use is from inside an ant script, but I can see the advantage and I'm very happy to make this change. David ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Adding attachments via the command line
On Sat, Jan 2, 2016 at 11:31 AM, David Vines wrote: > I now have a prototype for command line access to add attachments to wiki > pages and tech notes. I'd like to ask for any feedback on the command > itself before I polish my changes and put the changes up for review: > >fossil wiki attachment add ?PAGENAME? FILENAME [-t|--technote DATETIME ] > > Add an attachment to an existing wiki page or tech note. One of > PAGENAME or DATETIME must be specified. > > I made "attachment" as a noun to allow for the later addition of other > verbs like list and export. I don't propose to change the ticket since (a) > I don't need it myself and (b) the existing ticket command just modifies > the metadata for existing tickets and doesn't allow creation of tickets or > the addition of text to existing tickets. i like the idea but am concerned that "attachment" might be annoyingly long to type on the CLI. If you'll move it into its own top-level command then it could take advantage of fossil's built-in "auto-shortening" of top-level commands, e.g.: fossil att[achment] add ... If it's a subcommand of "wiki" then the ability to use any unique short form of it doesn't come for free (that only works for top-level commands). :-? - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
