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] Completely untagged commits ?

[bch]

Hi Dave.

 Don't fret! I'm not attributing this to malice or blaming -you-, but
something does look strange to me (on my local copy of the repo).

Cheers,

-bch

On 1/5/16, David Vines  wrote:
> On 05/01/2016 18:53, bch wrote:
>> How did we end up w/ dave.vines' completely untagged (no branch)
>> commits in the repository (or am I misreading what these are?) ?
>>
>> ref:
>>/info/b208bf75777604dc
>>/timeline?u=dave.vines=2016-01-05+10%3A12%3A56=200
>
> If I've messed this up, I do most humbly apologise and want to fix it
> ASAP - but I see this as tagged as "technoteattachcli", at least in the
> fossil-scm.org web ui.
>
> One curious aspect I do see is that the web ui has the annotation of
> "unpublished" against the creation of the branch. I did start by have a
> private branch which I then published - I do wonder if this might be
> part of the problem.
>
> David
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
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] Completely untagged commits ?

[David Vines]

On 05/01/2016 18:53, bch wrote:

How did we end up w/ dave.vines' completely untagged (no branch)
commits in the repository (or am I misreading what these are?) ?

ref:
   /info/b208bf75777604dc
   /timeline?u=dave.vines=2016-01-05+10%3A12%3A56=200


If I've messed this up, I do most humbly apologise and want to fix it 
ASAP - but I see this as tagged as "technoteattachcli", at least in the 
fossil-scm.org web ui.


One curious aspect I do see is that the web ui has the annotation of 
"unpublished" against the creation of the branch. I did start by have a 
private branch which I then published - I do wonder if this might be 
part of the problem.


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] Completely untagged commits ?

[bch]

On 1/5/16, Richard Hipp  wrote:
> On 1/5/16, Richard Hipp  wrote:
>> On 1/5/16, David Vines  wrote:
>>>
>>> One curious aspect I do see is that the web ui has the annotation of
>>> "unpublished" against the creation of the branch. I did start by have a
>>> private branch which I then published - I do wonder if this might be
>>> part of the problem.
>>>
>>
>> There was a "private" tag on that initial check-in.  I have cancelled
>> that tag.  But the check-in is still showing as "unpublished".  Must
>> be a bug somewhere.  A "fossil rebuild" will likely clear the problem.
>> I'll try that next...
>
> Even after rebuilding, the check-in shows up as "unpublished".
> There's a bug somewhere in the "private" tag handling.  Who can be the
> first to find it!

I think we've got a few hours until Stephan Beal wakes up...


> I went into the repository and manually did a "DELETE FROM private
> WHERE rid=(SELECT rid FROM blob WHERE uuid LIKE '5712fa8f133228f%')".
> That got the repo working again.  But that entry in the private table
> will probably reappear the next time the repo is rebuilt.
>
> But in the meantime, you can all sync the public repo and try to
> figure out what is the problem.
> --
> 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
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Completely untagged commits ?

[bch]

How did we end up w/ dave.vines' completely untagged (no branch)
commits in the repository (or am I misreading what these are?) ?

ref:
  /info/b208bf75777604dc
  /timeline?u=dave.vines=2016-01-05+10%3A12%3A56=200
___
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] Completely untagged commits ?

[bch]

Here's what I see on my *local* machine (see also attached ffox screenshot):

strathcona$ fossil timel
=== 2016-01-05 ===
10:12:56 [d4dc7ad8dc] [c541b6e734] Remove unintended white space
change in wiki.c (user: dave.vines)
08:40:09 [64a5ef28e5] [c541b6e734] Move attachment command from wiki.c
to attach.c (user: dave.vines)
08:34:24 [16f864af8f] [c541b6e734] Move attachment from wiki
subcommand to top level command (user: dave.vines)
04:52:59 [cd58f59a47] Update the built-in SQLite to the next 3.10.0
beta. (user: drh tags: trunk)
=== 2016-01-04 ===
23:29:36 [c3430c1a67] Edit [2c5a5e82be8c30d7|2c5a5e82be]: Edit
check-in comment. (user: aku)
03:41:15 [6f8f8667c9] Update manifests on tag change. (user: jan tags:
jan-manifest-tags)
03:10:27 [53f2e7c540] Filter tags. (user: jan tags: jan-manifest-tags)
02:54:39 [dacecc79aa] Handle the three manifest files separately so
manifest generation reconfigurations can be handled properly. (user:
jan tags: jan-manifest-tags)
02:16:47 [46b9adb70f] Conditionally save manifests on commit. (user:
jan tags: jan-manifest-tags)
00:36:40 [de30eec201] Code normalization; tabs->spaces. (user: jan
tags: jan-manifest-tags)
00:29:24 [c6f3eba715] Edit [e5b250959ad4ec15|e5b250959a]: Edit
check-in comment. (user: jan)
00:28:40 [aed6fe5308] Add manifest.tags to generated zips, and
decouple manifest and manifest.uuid. (user: jan tags:
jan-manifest-tags)
00:22:03 [185669ce21] Fix: Extract filename for manifest.tags. (user:
jan tags: jan-manifest-tags)
00:19:00 [6a56db89f6] Added a missing finalize. (user: jan tags:
jan-manifest-tags)
=== 2016-01-03 ===
23:55:15 [80ceedbdea] Add manifest.tags to tarballs when appropriate,
and decouple manifest and manifest.uuid. (user: jan tags:
jan-manifest-tags)
22:54:15 [142cb7aabd] Add manifest.tags to the list of potentially
reserved names and decouple manifest and manifest.uuid from each
other. (user: jan tags: jan-manifest-tags)
22:46:00 [226e7c2842] Fix; second argument of db_get_versioned() is
not that of db_get(). (user: jan tags: jan-manifest-tags)
--- line limit (20) reached ---


On 1/5/16, bch  wrote:
> Hi Dave.
>
>  Don't fret! I'm not attributing this to malice or blaming -you-, but
> something does look strange to me (on my local copy of the repo).
>
> Cheers,
>
> -bch
>
> On 1/5/16, David Vines  wrote:
>> On 05/01/2016 18:53, bch wrote:
>>> How did we end up w/ dave.vines' completely untagged (no branch)
>>> commits in the repository (or am I misreading what these are?) ?
>>>
>>> ref:
>>>/info/b208bf75777604dc
>>>/timeline?u=dave.vines=2016-01-05+10%3A12%3A56=200
>>
>> If I've messed this up, I do most humbly apologise and want to fix it
>> ASAP - but I see this as tagged as "technoteattachcli", at least in the
>> fossil-scm.org web ui.
>>
>> One curious aspect I do see is that the web ui has the annotation of
>> "unpublished" against the creation of the branch. I did start by have a
>> private branch which I then published - I do wonder if this might be
>> part of the problem.
>>
>> David
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
___
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] Completely untagged commits ?

[bch]

I just did another pull, and the branch tags showed up, so @drh, I
think your rebuild helped somewhat. Now to find out how the repo got
into it's "broken" state in the first place.

On 1/5/16, bch  wrote:
> On 1/5/16, Richard Hipp  wrote:
>> On 1/5/16, Richard Hipp  wrote:
>>> On 1/5/16, David Vines  wrote:

 One curious aspect I do see is that the web ui has the annotation of
 "unpublished" against the creation of the branch. I did start by have a
 private branch which I then published - I do wonder if this might be
 part of the problem.

>>>
>>> There was a "private" tag on that initial check-in.  I have cancelled
>>> that tag.  But the check-in is still showing as "unpublished".  Must
>>> be a bug somewhere.  A "fossil rebuild" will likely clear the problem.
>>> I'll try that next...
>>
>> Even after rebuilding, the check-in shows up as "unpublished".
>> There's a bug somewhere in the "private" tag handling.  Who can be the
>> first to find it!
>
> I think we've got a few hours until Stephan Beal wakes up...
>
>
>> I went into the repository and manually did a "DELETE FROM private
>> WHERE rid=(SELECT rid FROM blob WHERE uuid LIKE '5712fa8f133228f%')".
>> That got the repo working again.  But that entry in the private table
>> will probably reappear the next time the repo is rebuilt.
>>
>> But in the meantime, you can all sync the public repo and try to
>> figure out what is the problem.
>> --
>> 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
>>
>
___
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] Completely untagged commits ?

[Richard Hipp]

On 1/5/16, David Vines  wrote:
>
> One curious aspect I do see is that the web ui has the annotation of
> "unpublished" against the creation of the branch. I did start by have a
> private branch which I then published - I do wonder if this might be
> part of the problem.
>

There was a "private" tag on that initial check-in.  I have cancelled
that tag.  But the check-in is still showing as "unpublished".  Must
be a bug somewhere.  A "fossil rebuild" will likely clear the problem.
I'll try that next...

-- 
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] Completely untagged commits ?

[Richard Hipp]

On 1/5/16, Richard Hipp  wrote:
> On 1/5/16, David Vines  wrote:
>>
>> One curious aspect I do see is that the web ui has the annotation of
>> "unpublished" against the creation of the branch. I did start by have a
>> private branch which I then published - I do wonder if this might be
>> part of the problem.
>>
>
> There was a "private" tag on that initial check-in.  I have cancelled
> that tag.  But the check-in is still showing as "unpublished".  Must
> be a bug somewhere.  A "fossil rebuild" will likely clear the problem.
> I'll try that next...

Even after rebuilding, the check-in shows up as "unpublished".
There's a bug somewhere in the "private" tag handling.  Who can be the
first to find it!

I went into the repository and manually did a "DELETE FROM private
WHERE rid=(SELECT rid FROM blob WHERE uuid LIKE '5712fa8f133228f%')".
That got the repo working again.  But that entry in the private table
will probably reappear the next time the repo is rebuilt.

But in the meantime, you can all sync the public repo and try to
figure out what is the problem.
-- 
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

[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] Completely untagged commits ?

[Richard Hipp]

On 1/5/16, bch  wrote:
> I just did another pull, and the branch tags showed up, so @drh, I
> think your rebuild helped somewhat. Now to find out how the repo got
> into it's "broken" state in the first place.
>

The rebuild didn't help.  It was my manual DELETE of the offending
entry in the PRIVATE table of the database that fixed it.  But that
entry will reappear at the next rebuild, I suspect.
-- 
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] Completely untagged commits ?

[Richard Hipp]

On 1/5/16, bch  wrote:
> What's incorrect, the documentation, or the implementation ?

Both, IIRC.  I think you can convert a private branch to public by
cancelling the "private" tag.  But I don't think that feature is
completely operational right now.

But it has been over a year since I worked on any of that.  And I'm
tied up working on SQLite right this moment and can't stop to look.


>
> From private.wiki:
>
> After additional work, one might desire to publish the changes associated
> with a private branch.  The usual way to do this is to merge those
> changes into a public branch.  For example:
>
> 
> fossil update trunk
> fossil merge private
> fossil commit
> 
>
> The private branch remains private.  (There is no way to convert a private
> branch into a public branch.)  But all of the changes associated with
> the private branch are now folded into the public branch and are hence
> visible to other users of the project.
>
>
> On 1/5/16, Richard Hipp  wrote:
>> On 1/5/16, bch  wrote:
>>> I just did another pull, and the branch tags showed up, so @drh, I
>>> think your rebuild helped somewhat. Now to find out how the repo got
>>> into it's "broken" state in the first place.
>>>
>>
>> The rebuild didn't help.  It was my manual DELETE of the offending
>> entry in the PRIVATE table of the database that fixed it.  But that
>> entry will reappear at the next rebuild, I suspect.
>> --
>> 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
>>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>


-- 
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] Completely untagged commits ?

[David Vines]

On 05/01/2016 19:53, Richard Hipp wrote:

On 1/5/16, bch  wrote:

What's incorrect, the documentation, or the implementation ?


Both, IIRC.  I think you can convert a private branch to public by
cancelling the "private" tag.  But I don't think that feature is
completely operational right now.

But it has been over a year since I worked on any of that.  And I'm
tied up working on SQLite right this moment and can't stop to look.



And what I read (and was presumably misled by) was the help text on 
fossil publish which says "can be used (for example) to convert a 
private branch into a public branch."


Looking at the code in publish.c my current suspicion is that it marks 
everything as public in the branch except for the branch itself. Hence

the branch artifact has a "+private" tag record.

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] Completely untagged commits ?

[bch]

What's incorrect, the documentation, or the implementation ?

>From private.wiki:

After additional work, one might desire to publish the changes associated
with a private branch.  The usual way to do this is to merge those
changes into a public branch.  For example:


fossil update trunk
fossil merge private
fossil commit


The private branch remains private.  (There is no way to convert a private
branch into a public branch.)  But all of the changes associated with
the private branch are now folded into the public branch and are hence
visible to other users of the project.


On 1/5/16, Richard Hipp  wrote:
> On 1/5/16, bch  wrote:
>> I just did another pull, and the branch tags showed up, so @drh, I
>> think your rebuild helped somewhat. Now to find out how the repo got
>> into it's "broken" state in the first place.
>>
>
> The rebuild didn't help.  It was my manual DELETE of the offending
> entry in the PRIVATE table of the database that fixed it.  But that
> entry will reappear at the next rebuild, I suspect.
> --
> 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
>
___
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] Completely untagged commits ?

[Andy Bradford]

Thus said David Vines on Tue, 05 Jan 2016 20:08:40 +:

> And what I  read (and was presumably  misled by) was the  help text on
> fossil publish  which says  "can be  used (for  example) to  convert a
> private branch into a public branch."

If I'm not  mistaken, the ``fossil publish'' command was  intended to be
used with bundles, not private branches per se. As far as I know, it has
never been possible to mark a private branch as public.

I wondered about  private content being marked public  when I discovered
the content_make_public() function:

http://marc.info/?l=fossil-users=144565832340627=2

But I don't think I've ever seen a definitive answer.

Thanks,

Andy
-- 
TAI64 timestamp: 4000568c251f


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users