Re: [fossil-users] Versions & manifests

[Steve Stefanovich]

> > 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. 

I didn't mean the current checkout branch tag, just used that as
an example. I meant branch tag of the check-in you're getting the
source from, i.e. what's in the manifest.uuid.

>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.

I don't think you need such a special case. Maybe a better way is to extract
raw tags, or provide an option to do so, because then the branch tag is easily
distinguished:

C:\Temp>f timeline -t ci -R t.fossil
=== 2016-01-05 ===
08:02:44 [11a34d67d0] Branch 
(user: Steve tags: test_branch, branch_tag)
=== 2015-12-27 ===
02:45:54 [0a1fb00ed9] initial empty check-in 
(user: Steve tags: trunk, trunk_tag)
+++ no more data (2) +++

C:\Temp>f tag list --raw trunk -R t.fossil
branch=trunk
sym-trunk
sym-trunk_tag

C:\Temp>f tag list --raw test_branch -R t.fossil
branch=test_branch
sym-branch_tag
sym-test_branch
sym-trunk

Cheers,
Steve
___
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] Versions & manifests

[Jan Danielsson]

On 05/01/16 09:14, Steve Stefanovich wrote:
[---]
>>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.
> 
> I don't think you need such a special case. Maybe a better way is to extract
> raw tags, or provide an option to do so, because then the branch tag is easily
> distinguished:
[---]

   Ah, ok, gotcha -- I misunderstood.  I'm running low on time, but I'll
take a look.


-- 
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] Versions & manifests

[Jan Danielsson]

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] Versions & manifests

[Jan Danielsson]

On 01/01/16 18:43, Jan Danielsson wrote:
[---]
>Optimally the tagged version _is_ the source version. [...]

   I'm home sick, so I started working on this in the branch
jan-manifest-tags.

   I'd like some feedback on the settings semantics.  What I want to
accomplish is that any existing settings will not change any behavior.
Anyone who sets manifest to any value they are used to (0, 1, on, off,
true, false) will continue to get the same behavior as they always have.
 However I also wanted to decouple manifest and manifest.uuid from each
other when I added support for manifest.tags.  The reason for this is
simply because I use manifest.uuid, but the plain manifest I only use
for poking around in the repository (I only enable it locally and
typically only temporarily); in most cases I don't need it to be part of
tarballs and such.

   So the way it works now is that the manifest field is treated either
as before, but if it doesn't detect any of the standard booleans, it
treats the field as a sequence of flags, where 'r' means "generate raw
manifest", 'u' means "generate manifest.uuid and 't' means "generate
manufest.tags".

   I.e. to get them all:
   $ fossil set manifest rut

   To get only uuid and tags:
   $ fossil set manifest ut

   These will behave just as before:
   $ fossil set manifest on
   $ fossil set manifest false

   I gotta admit that mixing the old and the new settings semantics made
me feel uneasy, but I'm getting used to it -- which isn't necessarily a
good thing.  First impression feedback is appreciated, and if you don't
like it, suggest other possible solutions (which doesn't involve adding
another settings field).

   Also, since the three manifest settings are now essentially flags I
thought I'd make them all checkboxes in the settings web ui, but that
would require some rewiring of how the web settings interface works.

-- 
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] Versions & manifests

[Jan Danielsson]

Hello,

   drh and sgbeal brought up the following points:

   1) Make sure an existing [managed] manifest.tags isn't overwritten.

   2) fossil add needs to be made manifest.tags-aware.

   3) Tarballs and zips need to be made manifest.tags-aware.

   4) fossil clean needs to be made manifest.tags-aware.

   5) The issue of ignore-glob needing updating on projects which use
manifests.


   Point 2 & 4 are essentially the same, IIUC; the new file is returned
as an entry in fossil_reserved_name(), which causes a lot things to Just
Work(tm).

   Point 3 is done.

   AFAICT the reserved names are implicit in ignore-glob, so I think
that's taken care of as well.  One don't need to explicitly add manifest
and manifest.uuid to ignore-glob; so the same goes for manifest.tags.

   In addition the web settings ui has been updated and the "tag"
command will update the manifests (since tags are highly relevant to
manifest.tags).

   Anything which I call "done" should be considered only very lightly
tested.  I've written a simple script to run a few automated tests, and
they yield the expected results -- but I would be surprised if there
aren't cases I haven't covered.

   AFAICT there are only a few of us here who are actually using
manifests, so I understand if people aren't jumping at the opportunity
to test this, but I attached a test-script for those who are curious and
are willing to try it out.

   The one known todo-item is point 1 in the list.


-- 
Kind Regards,
Jan


fostagtest.sh
Description: Bourne shell script
___
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] Versions & manifests

[Steve Stefanovich]

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?

We use the combination of uuid and branch tag for versioning. 

S. 

  Original Message  
From: Jan Danielsson
Sent: Monday, 4 January 2016 16:03‎
Subject: Re: [fossil-users] Versions & manifests‎



___
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] Versions & manifests

[Stephan Beal]

On Fri, Jan 1, 2016 at 7:09 PM, Richard Hipp  wrote:

> (4) Commands like "fossil clean" need to be taught to not delete the
> "manifest.tags" file.
>
> What else am I forgetting?
>

The ignore-glob then potentially needs to be updated in projects which uses
that setting.

-- 
- 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

[fossil-users] Versions & manifests

[Jan Danielsson]

Hello,

   I have build systems which use the commit id from the manifest to
embed the commit artifact id in the binary.  I also, in most projects,
have an ordinal version number which is loosely coupled between the
repository and the build system/source in the sense that I can forget to
update the source when I tag a new version in the scm.

   Optimally the tagged version _is_ the source version.  I had a period
when I had a build system run "fossil status" and determined if there
were no changes and there was a -X.Y.Z tag, then X.Y.Z
would be used as a release version number.  However, I dislike the idea
of the build system requiring the fossil binary to build (in case
someone downloads the source in an archived form), so it never got past
a quick trial.

   (In case you're wondering, when the build system didn't detect a
"release" version it used a special (reserved) version number scheme
which we use for development builds).

   The manifest solves this issue neatly for the commit id; but can it
be made to solve it for version numbers with ordinality?

   How feasible would it be for fossil to in addition to manifest and
manifest.uuid write something like manifest.tags which is simply a file
which lists all (current) tags (newline-separated)?  Build scripts could
grep -X.Y.Z to determine the release version.  It would
also allow build systems to use scm tags to flag certain other
attributes; imagine an "experimental" tag, for instance.  (For those who
haven't used manifests: The neat thing with them is that they are a part
of generated source archives).

   It would also allow tagged version numbers to easily be put into
amalgamated sources, for those of us who like to include amalgamation
scripts with libraries.

   Settings-wise, I wouldn't want to add a new option for this, but
perhaps the "manifest" setting can grow from a simple boolean to
something along the line of a "off, on, full" setting.  The idea would
be to make the change completely non-intrusive and completely invisible
to users who have no need for it.

   Thoughts?

   Regarding feasibility; the question isn't whether it *can* be done,
the question is whether the queries are too costly to be able to keep
the "manifest.tags" updated when required.

-- 
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] Versions & manifests

[Richard Hipp]

On 1/1/16, Richard Hipp  wrote:
> On 1/1/16, Jan Danielsson  wrote:
>>
>>How feasible would it be for fossil to in addition to manifest and
>> manifest.uuid write something like manifest.tags which is simply a file
>> which lists all (current) tags (newline-separated)?
>
> The query to find relevant tags is fast and efficient.  The
> complications are these:
>
> (1) Before writing the manifest.tags file, we have to check to make
> sure it will not overwrite a user file under configuration management.
> It seems unlikely that any users have ever checked in a file named
> "manifest.tags", but you never know and we don't want to clobber their
> work.
>
> (2) The "fossil add" command should probably be extended to prohibit
> new instances of "manifest.tags" from being managed.
>
> (3) The tarball and ZIP-archive generators need to be enhanced to add
> in the "manifest.tags" file.
>

(4) Commands like "fossil clean" need to be taught to not delete the
"manifest.tags" file.

What else am I forgetting?
-- 
D. Richard Hipp
d...@sqlite.org
___
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] Versions & manifests

[Richard Hipp]

On 1/1/16, Jan Danielsson  wrote:
>
>How feasible would it be for fossil to in addition to manifest and
> manifest.uuid write something like manifest.tags which is simply a file
> which lists all (current) tags (newline-separated)?

The query to find relevant tags is fast and efficient.  The
complications are these:

(1) Before writing the manifest.tags file, we have to check to make
sure it will not overwrite a user file under configuration management.
It seems unlikely that any users have ever checked in a file named
"manifest.tags", but you never know and we don't want to clobber their
work.

(2) The "fossil add" command should probably be extended to prohibit
new instances of "manifest.tags" from being managed.

(3) The tarball and ZIP-archive generators need to be enhanced to add
in the "manifest.tags" file.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users