Re: [fossil-users] Initial empty checkin?

[Andy Bradford]

Thus said Andy Goth on Wed, 16 Aug 2017 10:47:56 -0500:

> What of this old thread? Are  the issues it discusses still pertinent,
> or have they been resolved?

I believe  all the  relevant issues were  actually resolved,  however, I
think it  was still unfavorable  given the  time that was  available for
testing the changes before release.

Personally,  I would  be  in  favor of  retaining  the  old behavior  by
default,  but allowing  a command  line option  to ``fossil  init'' that
would initialize a new repository without it.

Andy
-- 
TAI64 timestamp: 400059952b4d


___
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] Go's get cmd is getting support for Fossil

[Carlo Miron]

On Thu, Aug 17, 2017 at 12:35 AM, Kyle Shannon  wrote:

> Yes, it appears it does.  I'll send a change, thanks.

Thank *YOU* so much for your PR, Kyle!

㎝

-- 
|:**THE BEER-WARE LICENSE** *(Revision 42)*:
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
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] Go's get cmd is getting support for Fossil

[Kyle Shannon]

Yes, it appears it does.  I'll send a change, thanks.

On Wed, Aug 16, 2017 at 4:28 PM, Carlo Miron  wrote:
> On Wed, Aug 16, 2017 at 11:48 PM, Carlo Miron  wrote:
>
>> On Wed, Aug 16, 2017 at 9:03 PM, Gour  wrote:
>>
>>> Hello,
>>>
>>> I just noticed great news:
>>>
>>> https://go-review.googlesource.com/c/56190
>
> Shouldn't line 951 of src/cmd/go/internal/get/vcs.go be
>
> re: 
> `^(?P(?P([a-z0-9.\-]+\.)+[a-z0-9.\-]+(:[0-9]+)?(/~?[A-Za-z0-9_.\-]+)+?)\.(?Pbzr|git|hg|svn|fossil))(/~?[A-Za-z0-9_.\-]+)*$`,
>
> ?
>
> ㎝
>
> --
> |:**THE BEER-WARE LICENSE** *(Revision 42)*:
> |  wrote this mail. As long as you retain
> | this notice you can do whatever you want with this stuff.
> | If we meet some day, and you think this stuff is worth it,
> | you can buy me a beer in return.
> |--Carlo Miron :



-- 
Kyle
___
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] Go's get cmd is getting support for Fossil

[Carlo Miron]

On Wed, Aug 16, 2017 at 11:48 PM, Carlo Miron  wrote:

> On Wed, Aug 16, 2017 at 9:03 PM, Gour  wrote:
>
>> Hello,
>>
>> I just noticed great news:
>>
>> https://go-review.googlesource.com/c/56190

Shouldn't line 951 of src/cmd/go/internal/get/vcs.go be

re: 
`^(?P(?P([a-z0-9.\-]+\.)+[a-z0-9.\-]+(:[0-9]+)?(/~?[A-Za-z0-9_.\-]+)+?)\.(?Pbzr|git|hg|svn|fossil))(/~?[A-Za-z0-9_.\-]+)*$`,

?

㎝

-- 
|:**THE BEER-WARE LICENSE** *(Revision 42)*:
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
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] Go's get cmd is getting support for Fossil

[Carlo Miron]

On Wed, Aug 16, 2017 at 9:03 PM, Gour  wrote:

> Hello,
>
> I just noticed great news:
>
> https://go-review.googlesource.com/c/56190

W00t!!!1

㎝

-- 
|:**THE BEER-WARE LICENSE** *(Revision 42)*:
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
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] backing out an incorrect commit?

[Stephan Beal]

On Wed, Aug 16, 2017 at 9:59 PM, bch  wrote:

> That doesn't sound unreasonable. Sort of doubly-constrained 1) from newest
> to older, per branch 2) on conflict, retarget branch, go-to 1
>

That's basically it, at least hypothetically. In principal "easy", and the
code is in place to do all the un/re-deltification. It would "simply" be a
matter of back-tracking one commit at a time and cleaning up/reaping
now-dead artifacts as as you go.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"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

Re: [fossil-users] backing out an incorrect commit?

[bch]

On Aug 16, 2017 12:54, "Stephan Beal"  wrote:

On Wed, Aug 16, 2017 at 9:19 PM, bch  wrote:

>
>
> On Aug 16, 2017 12:10, "Stephan Beal"  wrote:
>
> It's hypothetically possible, and i investigated it 3 or 4 years ago, but
> the devil is in the details :/. Not impossible, but you have to take care
> of details like properly undelta'ing anything which is deltad against the
> to-be-popped head.
>
>
>
> Oh - I didn't realize that's the direction the deltas worked...
>


Fossil tries to keep the undelta'd copy at the head, since it's the one
most likely to be accessed. That's not a guaranty, though - just a
preference/habit. Thus if you pop the head, you need to make sure and go
undelta all artifacts in that head which are not referenced by anything
else in the tree.


>
> At the time i wasn't confident enough in my knowhow of the internals to
> implement it. Also, it would only work up until you push to a remote, at
> which point all bets are off.
>
>
> Well... I suspect that's true, but still not entirely useless depending on
> context. Depending on project, one may simply redistribute the new
> ("popped") repo out to remotes and pick up from there.
>

Right. i believe there are certainly uses for it.

Another detail i forgot about earlier is the handling of branches: you can
only pop  from the tip of any given branch and only if no other branch
derives from that point in the branch. As soon as something derives from
what you want to pop, you have to go pop all that off first. When i
realized how ugly that gets, i stopped researching an implementation :/.


That doesn't sound unreasonable. Sort of doubly-constrained 1) from newest
to older, per branch 2) on conflict, retarget branch, go-to 1

Right?



-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[Stephan Beal]

On Wed, Aug 16, 2017 at 9:54 PM, Stephan Beal  wrote:

> just a preference/habit. Thus if you pop the head, you need to make sure
> and go undelta all artifacts in that head which are not referenced by
> anything else in the tree.
>

Parson me: you'd need to undelta anything in the NEW head and reap/purge
any popped-off artifacts which are no longer referenced by anything in the
repo.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"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

Re: [fossil-users] backing out an incorrect commit?

[Stephan Beal]

On Wed, Aug 16, 2017 at 9:19 PM, bch  wrote:

>
>
> On Aug 16, 2017 12:10, "Stephan Beal"  wrote:
>
> It's hypothetically possible, and i investigated it 3 or 4 years ago, but
> the devil is in the details :/. Not impossible, but you have to take care
> of details like properly undelta'ing anything which is deltad against the
> to-be-popped head.
>
>
>
> Oh - I didn't realize that's the direction the deltas worked...
>


Fossil tries to keep the undelta'd copy at the head, since it's the one
most likely to be accessed. That's not a guaranty, though - just a
preference/habit. Thus if you pop the head, you need to make sure and go
undelta all artifacts in that head which are not referenced by anything
else in the tree.


>
> At the time i wasn't confident enough in my knowhow of the internals to
> implement it. Also, it would only work up until you push to a remote, at
> which point all bets are off.
>
>
> Well... I suspect that's true, but still not entirely useless depending on
> context. Depending on project, one may simply redistribute the new
> ("popped") repo out to remotes and pick up from there.
>

Right. i believe there are certainly uses for it.

Another detail i forgot about earlier is the handling of branches: you can
only pop  from the tip of any given branch and only if no other branch
derives from that point in the branch. As soon as something derives from
what you want to pop, you have to go pop all that off first. When i
realized how ugly that gets, i stopped researching an implementation :/.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"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

Re: [fossil-users] backing out an incorrect commit?

[bch]

On Aug 16, 2017 12:10, "Stephan Beal"  wrote:

It's hypothetically possible, and i investigated it 3 or 4 years ago, but
the devil is in the details :/. Not impossible, but you have to take care
of details like properly undelta'ing anything which is deltad against the
to-be-popped head.



Oh - I didn't realize that's the direction the deltas worked...

At the time i wasn't confident enough in my knowhow of the internals to
implement it. Also, it would only work up until you push to a remote, at
which point all bets are off.


Well... I suspect that's true, but still not entirely useless depending on
context. Depending on project, one may simply redistribute the new
("popped") repo out to remotes and pick up from there.


-bch


You should be able to pop any number of consecutive heads up until that
point, though.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Aug 16, 2017 20:30, "bch"  wrote:

>   We really should have (and it's not against philosophy) ability to
> pop commits off top, though. I've miscommited to a branch, and I think
> I'd just like to redo it, to say nothing of accidentally committing
> something sensitive like a credit card number or password.
>
> -bch
>
> On 8/16/17, Stephan Beal  wrote:
> > On Wed, Aug 16, 2017 at 8:15 PM, Stephan Beal 
> > wrote:
> >
> >> On Wed, Aug 16, 2017 at 7:59 PM, Steve Schow  wrote:
> >> > Is that possible at all or if not, what is the best way to handle that
> >> kind of situation with fossil?
> >>
> >> Fossil is designed to never forget anything, not even mistakes. It's
> >> possible to move a commit to a new branch, thereby "kind of hiding it",
> >> but
> >> not to remove it.
> >>
> >
> > Lol - seems we were all typing at the same time.
> >
> > --
> > - stephan beal
> > http://wanderinghorse.net/home/stephan/
> > "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 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] backing out an incorrect commit?

[Stephan Beal]

It's hypothetically possible, and i investigated it 3 or 4 years ago, but
the devil is in the details :/. Not impossible, but you have to take care
of details like properly undelta'ing anything which is deltad against the
to-be-popped head. At the time i wasn't confident enough in my knowhow of
the internals to implement it. Also, it would only work up until you push
to a remote, at which point all bets are off. You should be able to pop any
number of consecutive heads up until that point, though.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Aug 16, 2017 20:30, "bch"  wrote:

>   We really should have (and it's not against philosophy) ability to
> pop commits off top, though. I've miscommited to a branch, and I think
> I'd just like to redo it, to say nothing of accidentally committing
> something sensitive like a credit card number or password.
>
> -bch
>
> On 8/16/17, Stephan Beal  wrote:
> > On Wed, Aug 16, 2017 at 8:15 PM, Stephan Beal 
> > wrote:
> >
> >> On Wed, Aug 16, 2017 at 7:59 PM, Steve Schow  wrote:
> >> > Is that possible at all or if not, what is the best way to handle that
> >> kind of situation with fossil?
> >>
> >> Fossil is designed to never forget anything, not even mistakes. It's
> >> possible to move a commit to a new branch, thereby "kind of hiding it",
> >> but
> >> not to remove it.
> >>
> >
> > Lol - seems we were all typing at the same time.
> >
> > --
> > - stephan beal
> > http://wanderinghorse.net/home/stephan/
> > "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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Go's get cmd is getting support for Fossil

[Gour]

Hello,

I just noticed great news:

https://go-review.googlesource.com/c/56190


Sincerely,
Gour

-- 
The work of a man who is unattached to the modes of material
nature and who is fully situated in transcendental knowledge
merges entirely into transcendence.


___
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] backing out an incorrect commit?

[bch]

  We really should have (and it's not against philosophy) ability to
pop commits off top, though. I've miscommited to a branch, and I think
I'd just like to redo it, to say nothing of accidentally committing
something sensitive like a credit card number or password.

-bch

On 8/16/17, Stephan Beal  wrote:
> On Wed, Aug 16, 2017 at 8:15 PM, Stephan Beal 
> wrote:
>
>> On Wed, Aug 16, 2017 at 7:59 PM, Steve Schow  wrote:
>> > Is that possible at all or if not, what is the best way to handle that
>> kind of situation with fossil?
>>
>> Fossil is designed to never forget anything, not even mistakes. It's
>> possible to move a commit to a new branch, thereby "kind of hiding it",
>> but
>> not to remove it.
>>
>
> Lol - seems we were all typing at the same time.
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> "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

Re: [fossil-users] backing out an incorrect commit?

[Stephan Beal]

On Wed, Aug 16, 2017 at 8:15 PM, Stephan Beal  wrote:

> On Wed, Aug 16, 2017 at 7:59 PM, Steve Schow  wrote:
> > Is that possible at all or if not, what is the best way to handle that
> kind of situation with fossil?
>
> Fossil is designed to never forget anything, not even mistakes. It's
> possible to move a commit to a new branch, thereby "kind of hiding it", but
> not to remove it.
>

Lol - seems we were all typing at the same time.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"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

Re: [fossil-users] backing out an incorrect commit?

[Stephan Beal]

On Wed, Aug 16, 2017 at 7:59 PM, Steve Schow  wrote:
> Is that possible at all or if not, what is the best way to handle that
kind of situation with fossil?

Fossil is designed to never forget anything, not even mistakes. It's
possible to move a commit to a new branch, thereby "kind of hiding it", but
not to remove it.

To move a commit:

fossil ui
select the commit in the timeline
Find the "edit" link and click it.
Find the "Make this check-in the start of a new branch named", give it a
name, and check that checkbox.

Fossil has an option called "shunning" for removing "really bad" mistakes,
such as credentials and illegally copied materials, but that is a "nuclear
option" which can have side effects and is not intended to be used for
"honest, but harmless, mistakes".

--
- stephan beal
http://wanderinghorse.net/home/stephan/
"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

Re: [fossil-users] backing out an incorrect commit?

[Roy Keene]

Steve,

	Usually what is done here is the incorrect commit is moved to a 
different branch, which is typically hidden.  This can be done using 
"fossil amend".  Then you update to the new head of your branch (the 
previous commit) using "fossil update" and retry your commit.


It's also possible to shun the commit artifact on every system that has 
learned of it (given that no new commits are based off it) and a rebuild 
will drop the un-referenced data artifact.  This is not recommended in the 
normal case of a simple error being made, since you'll have to touch every 
clone that has the commit artifact.


Thanks,
Roy Keene

On Wed, 16 Aug 2017, Steve Schow wrote:

I know the fossil paradigm generally frowns on the idea of undoing 
commits.  Please tell me your thoughts about the best approach to handle 
the following situation.


a few file is added to the checkout and committed.  So the commit has 
one new file, nothing else.  It is later determined that the entirely 
wrong version of that file was committed for the first version of the 
file and we?d like to back it out to do it properly?


Is that possible at all or if not, what is the best way to handle that 
kind of situation with fossil?



___
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] backing out an incorrect commit?

[Richard Hipp]

On 8/16/17, Steve Schow  wrote:
> I know the fossil paradigm generally frowns on the idea of undoing commits.
> Please tell me your thoughts about the best approach to handle the following
> situation.
>
> a few file is added to the checkout and committed.  So the commit has one
> new file, nothing else.  It is later determined that the entirely wrong
> version of that file was committed for the first version of the file and
> we’d like to back it out to do it properly…
>
> Is that possible at all or if not, what is the best way to handle that kind
> of situation with fossil?

To "undo" a commit:

(1)  Bring up the /info page for the bad commit in the web interface.
(Use "fossil ui" if you do not have a server at hand.)

(2)  Click on the "edit" link to the right of the "Other Links:" label

(3)  Click on "Make this check-in the start of a new branch named:"
and type in "mistake" for the new branch name.

(4)  Click on "Mark this leaf as closed"

(5)  Edit the check-in comment to explain why the check-in is being backed out.

(6)  Click the "Apply" button

(7)  You are done with the web interface for the moment.  Go back to
your shell in your check-out directory and type "fossil update trunk"
to move your check-out back to what it was before you made the bad
check-in.

There are lots of examples of this in the SQLite source tree.  One
such example: https://www.sqlite.org/src/timeline?c=4b0f44848

-- 
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] backing out an incorrect commit?

[Steve Schow]

I know the fossil paradigm generally frowns on the idea of undoing commits.  
Please tell me your thoughts about the best approach to handle the following 
situation.

a few file is added to the checkout and committed.  So the commit has one new 
file, nothing else.  It is later determined that the entirely wrong version of 
that file was committed for the first version of the file and we’d like to back 
it out to do it properly…

Is that possible at all or if not, what is the best way to handle that kind of 
situation with fossil?


___
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] Two easy questions

[Roy Keene]

I have not read all this thread, but it seems to be centered around 
release engineering.  The goal, as I understand it, is to create a release 
and when that release is installed somewhere be aware of what release it 
is.


For this kind of thing I use a release engineering script called 
"makearch":  https://chiselapp.com/user/rkeene/repository/makearch/artifact/6250403d86ce0f58


In addition to being able to replace keywords in files (specified in 
makearch.info), it will attempt to ensure that the release is consistent, 
and basically working.


I use this for all my software releases.  Here are some example 
makearch.info files:

1. KitCreator: 
https://kitcreator.rkeene.org/fossil/artifact/2d5da9bed6be27de
2. Build-CC: http://build-cc.rkeene.org/fossil/artifact/2503d2429f6aab44
3. tcc4tcl: 
https://chiselapp.com/user/rkeene/repository/tcc4tcl/artifact/f99b7196f56e6f83
4. AppFS: http://appfs.rkeene.org/web/artifact/41bb149458ce926b
5. Tcl Web App Framework: 
https://chiselapp.com/user/rkeene/repository/webapp/artifact/d9bd7447b870ca6a
6. TUAPI: 
https://chiselapp.com/user/rkeene/repository/tuapi/artifact/587f2c762e4b94fa
7. makearch itself: 
https://chiselapp.com/user/rkeene/repository/makearch/artifact/1d478f607dd5f327

(I use it for a lot more projects, but that's a pretty good sampling of 
different kinds)


Thanks,
Roy Keene

On Wed, 16 Aug 2017, Stephan Beal wrote:


On Wed, Aug 16, 2017 at 7:17 PM, David Mason  wrote:
  Wow... longest thread I've ever seen.


Naw - there've been a few longer ones.
 
  Then go to 
localhost:8081/artifact/1bea11bf4a97b012e7d8b17c71a7d444f0b5a5aa
and you'll get the exact file you're looking for.  Of course, if someone edited 
the file you're SOL. There may be a command-line way to do
this, but I can't find it.


[stephan@host:~]$ f help whatis
Usage: f whatis NAME

Resolve the symbol NAME into its canonical artifact hash
artifact name and provide a description of what role that artifact
plays.

Options:

   --type TYPE          Only find artifacts of TYPE (one of: 'ci', 't',
                        'w', 'g', or 'e').
   -v|--verbose         Provide extra information (such as the RID)



But, correct: if someone edits the file (i.e. changes the hash) then this is 
useless.

--
- stephan beal
http://wanderinghorse.net/home/stephan/"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

Re: [fossil-users] Two easy questions

[Johan Kuuse]

On Wed, Aug 16, 2017 at 7:19 PM, Stephan Beal  wrote:
> On Wed, Aug 16, 2017 at 7:17 PM, David Mason  wrote:
>>
>> Wow... longest thread I've ever seen.
>
>
> Naw - there've been a few longer ones.
>
>>
>> Then go to
>> localhost:8081/artifact/1bea11bf4a97b012e7d8b17c71a7d444f0b5a5aa
>> and you'll get the exact file you're looking for.  Of course, if someone
>> edited the file you're SOL. There may be a command-line way to do this, but
>> I can't find it.
>

Command-line way:
To get the web page:
printf "GET /artifact/`shasum YOURFILE | cut -d ' ' -f 1`
HTTP/1.0\n\n" | fossil test-http
Whatis:
fossil whatis `shasum YOURFILE | cut -d ' ' -f 1`

But, as Stephan already mentioned, if YOURFILE has been modified since
the last commit, this will not work.

BR,
Johan

>
> [stephan@host:~]$ f help whatis
> Usage: f whatis NAME
>
> Resolve the symbol NAME into its canonical artifact hash
> artifact name and provide a description of what role that artifact
> plays.
>
> Options:
>
>--type TYPE  Only find artifacts of TYPE (one of: 'ci', 't',
> 'w', 'g', or 'e').
>-v|--verbose Provide extra information (such as the RID)
>
>
>
> But, correct: if someone edits the file (i.e. changes the hash) then this is
> useless.
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> "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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two easy questions

[Stephan Beal]

On Wed, Aug 16, 2017 at 7:17 PM, David Mason  wrote:

> Wow... longest thread I've ever seen.
>

Naw - there've been a few longer ones.


> Then go to localhost:8081/artifact/1bea11bf4a97b012e7d8b17c71a7d4
> 44f0b5a5aa
> and you'll get the exact file you're looking for.  Of course, if someone
> edited the file you're SOL. There may be a command-line way to do this, but
> I can't find it.
>

[stephan@host:~]$ f help whatis
Usage: f whatis NAME

Resolve the symbol NAME into its canonical artifact hash
artifact name and provide a description of what role that artifact
plays.

Options:

   --type TYPE  Only find artifacts of TYPE (one of: 'ci', 't',
'w', 'g', or 'e').
   -v|--verbose Provide extra information (such as the RID)



But, correct: if someone edits the file (i.e. changes the hash) then this
is useless.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"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

Re: [fossil-users] Two easy questions

[David Mason]

Wow... longest thread I've ever seen.  I scanned through and didn't see
mention of the simplest solution, if you have shasum available.

> shasum urltags.js
1bea11bf4a97b012e7d8b17c71a7d444f0b5a5aa
> fossil ui

Then go to localhost:8081/artifact/1bea11bf4a97b012e7d8b17c71a7d444f0b5a5aa
and you'll get the exact file you're looking for.  Of course, if someone
edited the file you're SOL. There may be a command-line way to do this, but
I can't find it.

../Dave
___
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] toc.tcl

[dewey.hyl...@gmail.com]

> - On Aug 16, 2017, at 11:37 AM, Andy Goth andrew.m.g...@gmail.com wrote:
>
> First off, I'm sorry I've been so incredibly busy with work and business
> travel, no time for Fossil development or even reading the mailing list.
>  The only issues I've been able to dink on lately are those that were
> stopping me from getting my work done.  I'm trying to change jobs so I
> might have a shot at working fewer than one hundred hours a week (no
> joke).  I have, however, been continuing to add to my Fossil TODO list,
> taking notes of bugs and features I'd like to look at someday.  If I
> ever get some free time, I have a lot planned.
> 
> With that out of the way, onward to the subject of this email.  Here's a
> short Tcl script I wrote the other day to put a table of contents in a
> Markdown document.
> 
> https://chiselapp.com/user/andy/repository/brush/file/doc/toc.tcl
> 
> Here's example output:
> 
> https://chiselapp.com/user/andy/repository/brush/doc/trunk/doc/concepts.md
> 
> To use, put  and  lines in your Markdown file, then
> run toc.tcl with your filename as an argument.  By design, it only works
> with #- and ##-style headings, not underlines.  If the file already
> contains a table of contents, it will be replaced.
> 
> Rerun the script after adding, removing, or renaming any first- or
> second-level headings.

I've been wishing for something similar to the TOC macro available in
moinmoin, and this is fairly close. The only thing missing from my
perspective is a link at each heading which points back to the top.

I don't know jack about TCL, but perhaps it's time for me to look into it!

I appreciate your work on this! 
___
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] Initial empty checkin?

[Andy Goth]

On 07/17/17 03:50, Jan Nijtmans wrote:

The patch below modifies Fossil not to create the initial empty
commit. (I always build Fossil with this patch). Everything works
fine without initial empty commit, the reason this was in Fossil is
just historical. Nowadays, there - indeed - is no reason any more
to create an empty initial commit, in my opinion is confuses
more than that it helps anything. Your mail tells me enough 


What of this old thread?  Are the issues it discusses still pertinent, 
or have they been resolved?


http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19845.html
___
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] Fossil version 2.3 - 10th anniversary edition

[Andy Goth]

On 07/12/17 13:50, Richard Hipp wrote:

The current plan is to release the 10th anniversary edition of Fossil,
version 2.3, on 2017-07-21.


I've been more-or-less keeping SlackBuilds up-to-date on Fossil 
releases, even though it's been a long time since I announced that I'm 
doing this.  Earlier this year I expanded my build script README to do a 
better job of explaining what's so cool about Fossil.  Have a look:


https://slackbuilds.org/repository/14.2/development/fossil/

If anyone has any suggestions or corrections, please let me know so I 
can incorporate them into the README for the SlackBuild for the next 
Fossil release.

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

[fossil-users] toc.tcl

[Andy Goth]

First off, I'm sorry I've been so incredibly busy with work and business 
travel, no time for Fossil development or even reading the mailing list. 
 The only issues I've been able to dink on lately are those that were 
stopping me from getting my work done.  I'm trying to change jobs so I 
might have a shot at working fewer than one hundred hours a week (no 
joke).  I have, however, been continuing to add to my Fossil TODO list, 
taking notes of bugs and features I'd like to look at someday.  If I 
ever get some free time, I have a lot planned.


With that out of the way, onward to the subject of this email.  Here's a 
short Tcl script I wrote the other day to put a table of contents in a 
Markdown document.


https://chiselapp.com/user/andy/repository/brush/file/doc/toc.tcl

Here's example output:

https://chiselapp.com/user/andy/repository/brush/doc/trunk/doc/concepts.md

To use, put  and  lines in your Markdown file, then 
run toc.tcl with your filename as an argument.  By design, it only works 
with #- and ##-style headings, not underlines.  If the file already 
contains a table of contents, it will be replaced.


Rerun the script after adding, removing, or renaming any first- or 
second-level headings.

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