Re: [fossil-users] Mailing list shutting down...

[Steve Schow]

Yea I agree, this is nice stuff to have, but in my view is not compelling for 
fossil which sets itself apart by being lightweight and simple.  There are 
numerous collaborative development platforms out there already.  I’ve messed 
around with a few of them and they are definitely cool and if I had a larger 
team working on stuff I’d definitely consider them over fossil for exactly the 
reasons you lay out.  However, I do not feel that Fossil is in the same space 
as them, it sets itself apart by being lightweight and simple and addresses the 
core needs of SCM, with a "good enough" ticketing system for a few people to 
collaborate on”.  There are actually many things about the ticketing and SCM in 
fossil which are bare bones compared to what I am used to in the workplace and 
have caused me to wish for something more elaborate in terms of peer review 
workflow, etc…but at the end of the day, the real strength of fossil its is 
simplicity and lightweight nature..so those kinds of advanced features will 
probably never get there and that’s fine.  I think fossil is great for what it 
is.  What you’re hoping for would be a very large development effort to obtain 
in fossil, and then it would cease to r itself from the other large offerings 
that are already out there, as the simple lightweight solution.


> On Jun 13, 2018, at 1:12 PM, Warren Young  wrote:
> 
> 
> 
>> Collaboration such as what we see on GitHub, etc..would be cool, don’t get 
>> me wrong, but in my opinion would greatly add to complexity in fossil.  I 
>> would be using one of those solutions already if I wanted a big complicated 
>> collaborative platform like that.
> 
> Any software project with more than one remote member needs such a thing.  
> For such projects, a discussion forum is probably more important than a wiki 
> or ticket tracker.
> 
> I think it’s fair to consider some kind of discussion forum an essential tool 
> for software development collaboration, which puts it right in Fossil’s space.
> ___
> 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] Mailing list shutting down...

[Steve Schow]

Here are some forum solutions that have been around a long time and a lot of 
people using them.  both work with sqlite:


https://www.phpbb.com <https://www.phpbb.com/>
https://mybb.com <https://mybb.com/>


more info about many more here:

https://en.wikipedia.org/wiki/Comparison_of_Internet_forum_software 
<https://en.wikipedia.org/wiki/Comparison_of_Internet_forum_software>


> On Jun 13, 2018, at 12:55 PM, Steve Schow  wrote:
> 
> As a certified forum junkie…I’ll add my two cents…
> 
> While it would be cool to have a forum type of capability built into fossil, 
> I do think that would end up being a very deep rabbit hole and one of the 
> things i love about fossil is the simplicity of it.  There are other deep 
> solutions such as redmine and others which provide deep collaboration 
> capabilities…which is where that kind of feature would lead to.  Otherwise, 
> in my mind, there is not much purpose of building it into fossil itself.  
> Collaboration such as what we see on GitHub, etc..would be cool, don’t get me 
> wrong, but in my opinion would greatly add to complexity in fossil.  I would 
> be using one of those solutions already if I wanted a big complicated 
> collaborative platform like that.
> 
> In terms of writing your own mail list software, I don’t know if that makes 
> that much sense either.  You might as well just move us to yahoo groups or 
> google groups or something like that and be done with it.  email is 
> fundamentally insecure and prone to spamming there is not much way around 
> that.
> 
> In terms of converting this list to a forum, an idea I whole heartedly 
> support, there are numerous open source solutions out there for rolling out 
> your own forum, but yes, it does mean having a machine decked out usually 
> with MySQL, but not always…and possibly apache, but not always.  There are a 
> few solutions that are commonly in use and basically use the same kind of 
> markdown and most people are pretty comfortable with BBCode, for example, by 
> now.  There are a few others.  There are some other new frameworks still in 
> early stages, that are more elaborate, but in my mind its mostly eye candy, 
> with LIKE buttons and stuff like that which is kind of overkill as a 
> replacement for mailman.  One of the old standby’s that are in use all over 
> the internet are probably the way to go here.
> 
> Some advantages of a web based forum are that old threads can live for years 
> and be revisited at any time by anyone, very easily, with searching, etc..  
> Moderation and membership can be controlled perhaps more easily. 
> 
> 
>> On Jun 13, 2018, at 9:18 AM, Richard Hipp  wrote:
>> 
>> On 6/13/18, Warren Young  wrote:
>>> If you do this atop Fossil, then you end up inches away from being able to
>>> provide an oft-wanted feature: email notifications on checkins, wiki article
>>> changes, and other Fossil events.
>> 
>> Indeed, there are many advantages to just tacking a forum capability
>> onto Fossil.  But there are also disadvantages.  The biggest problem I
>> see is that one does not necessarily want the standard Fossil page
>> header and footer to appear on the forum pages.  People looking for
>> help with an SQLite question do not need to see "Timeline", "Files",
>> "Branches", "Tags", and "Tickets" menu items across the top of the
>> page.  (ex: https://www.sqlite.org/src/doc/trunk/README.md)
>> 
>> -- 
>> 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Mailing list shutting down...

[Steve Schow]

As a certified forum junkie…I’ll add my two cents…

While it would be cool to have a forum type of capability built into fossil, I 
do think that would end up being a very deep rabbit hole and one of the things 
i love about fossil is the simplicity of it.  There are other deep solutions 
such as redmine and others which provide deep collaboration capabilities…which 
is where that kind of feature would lead to.  Otherwise, in my mind, there is 
not much purpose of building it into fossil itself.  Collaboration such as what 
we see on GitHub, etc..would be cool, don’t get me wrong, but in my opinion 
would greatly add to complexity in fossil.  I would be using one of those 
solutions already if I wanted a big complicated collaborative platform like 
that.

In terms of writing your own mail list software, I don’t know if that makes 
that much sense either.  You might as well just move us to yahoo groups or 
google groups or something like that and be done with it.  email is 
fundamentally insecure and prone to spamming there is not much way around that.

In terms of converting this list to a forum, an idea I whole heartedly support, 
there are numerous open source solutions out there for rolling out your own 
forum, but yes, it does mean having a machine decked out usually with MySQL, 
but not always…and possibly apache, but not always.  There are a few solutions 
that are commonly in use and basically use the same kind of markdown and most 
people are pretty comfortable with BBCode, for example, by now.  There are a 
few others.  There are some other new frameworks still in early stages, that 
are more elaborate, but in my mind its mostly eye candy, with LIKE buttons and 
stuff like that which is kind of overkill as a replacement for mailman.  One of 
the old standby’s that are in use all over the internet are probably the way to 
go here.

Some advantages of a web based forum are that old threads can live for years 
and be revisited at any time by anyone, very easily, with searching, etc..  
Moderation and membership can be controlled perhaps more easily. 


> On Jun 13, 2018, at 9:18 AM, Richard Hipp  wrote:
> 
> On 6/13/18, Warren Young  wrote:
>> If you do this atop Fossil, then you end up inches away from being able to
>> provide an oft-wanted feature: email notifications on checkins, wiki article
>> changes, and other Fossil events.
> 
> Indeed, there are many advantages to just tacking a forum capability
> onto Fossil.  But there are also disadvantages.  The biggest problem I
> see is that one does not necessarily want the standard Fossil page
> header and footer to appear on the forum pages.  People looking for
> help with an SQLite question do not need to see "Timeline", "Files",
> "Branches", "Tags", and "Tickets" menu items across the top of the
> page.  (ex: https://www.sqlite.org/src/doc/trunk/README.md)
> 
> -- 
> 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] web UI for a working checkout?

[Steve Schow]

Oh absolutely.  Its just fossil.  For me I can see two benefits to putting 
source on a public site like that.

1 - uptime.  Don’t have to worry about keeping my own fossil server up and 
running 24/7.  

2 - longevity, which is why I asked about that.  If I post some code on the 
internet, my desire will be for it to last pretty much forever.  Nobody uses 
source forge anymore, but you can still go there and download code that has 
been there a very long time.  The original author doesn’t have to worry about 
reposting it somewhere else again later.  Github is a fairly permanent source 
repository, I do not see that going away any time soon.  It will be around for 
decades.  Thus it is a very good place to place code that you want to not only 
work on publically, but just share with the world publicly and indefinitely.

However, I also do not like git much at all.  AT ALL.  You all know the reasons 
why already.  Besides the much discussed flaws with git, I just love that 
fossil has ticketing and versioning and wiki all built into one lightweight 
easy to install binary.  I tried messing around with all the other things 
people are using, and they were nightmare installs with MySQL or Postgres just 
to get started and basically way too complicated for small to medium projects.  
Plus they generally require you to use git…bleh..

Right now my thoughts are that if I create some kind of open source thing or 
something that I want to share with others, I feel like I would want to do all 
my work using fossil for tickets and version control, but then if I want to 
share my ongoing changes on github it would be a pain in the neck.

I guess chiselapp.com is pretty cool, if I find myself needing to do a 
multi-developer project or work on something where I hope others can 
contribute, then that would be better to avoid having to expose my own fossil 
server to the WAN.  I would get the uptime.  I’m pretty sure it will not last 
for decades, so I would have to consider this as most likely a temporary 
solution for publicly sharing the code on long term basis.

Fossil is so easy to install, its kind of a moot point…really don’t need it.  
Except for like I said..the two reasons above and keep your own server off the 
WAN.



> On Sep 30, 2017, at 12:34 PM, Andy Bradford 
> <amb-sendok-1509388468.kfbdnedbbkhghgefp...@bradfords.org> wrote:
> 
> Thus said Steve Schow on Fri, 29 Sep 2017 15:43:38 -0600:
> 
>> Who is hosting  that and what is the longevity  compared to github and
>> others?
> 
> Longevity on the Internet seems to  be an often nebulous thing. How long
> was Google Code (code.google.com) around? How long did Source Forge last
> before people started ditching it?
> 
> The nice thing  about chiselapp.com is that it's really  just Fossil. If
> chiselapp.com dies, you  still have your source (assuming  you clone and
> sync with chiselapp.com frequently) and it  wouldn't take much to find a
> new host to put it on.
> 
> Andy
> -- 
> TAI64 timestamp: 400059cfe3d8
> 
> 

___
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] web UI for a working checkout?

[Steve Schow]

No the use case is not for development, just a simple use case of version 
control without command line access.

I agree, in real development situations everyone should have a cloned repo and 
work locally.  Different use case.

But the web GUI control over the checkout would still have usefulness even in a 
machine where someone has complete command line access, such as their local 
machine.   If I roll something out it will have the ability, for example, to 
keep track of a current feature ticket and automatically add it with a commit.  
Being able to easily view a diff of what is about to be committed is very 
useful, etc... all can be made a bit more intuitive and even provide and 
overview such as always showing all currently changed files or a tree view that 
shows all files from the repo and unadded files colored differently, changed 
files also differently, etc.  doing it in the web just also makes it useful on 
a headless box is all, regardless of whether you have shell access

Sent from my iPhone

> On Sep 29, 2017, at 5:33 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:
> 
>> On 9/29/2017 4:43 PM, Steve Schow wrote:
>>> On Sep 29, 2017, at 2:46 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:
>>> http://chiselapp.com/
>> 
>> Hey thats pretty cool, I was not even aware of that site!  I am going
>> to check that out, I guess that’s a decent way to keep a repo public,
>> then I can clone it here locally for working on stuff.
> 
> Spread the word!
> 
>> But that webui just looks pretty much like the same one built into the
>> fossil binary, yes?
> 
> When you're viewing any particular repository, yes.  Chisel provides
> everything else surrounding the repositories.
> 
>> Who is hosting that and what is the longevity compared to github and
>> others?
> 
> Roy Keene can answer these questions.
> 
>> Primary interest right now is in using a headless machine that will be
>> hosting a repo.  And often users will not have command line access
>> either.  In the simplest case, I could set it up, with web ui access
>> to the repo itself, but then always require them to clone the repo on
>> another machine and do all their edits there and push their changes
>> back to remote master repo.
> 
> That is the basic arrangement Fossil was designed for.
> 
>> But it turns out there is also a use case for them being able to add
>> files and commits to the repo directly on the headless linux box
>> without having to clone the repo to another client machine.
> 
> I supposed one could call this a hosted development environment.  Though
> let me add to what I said earlier (needing an editor, etc.) to point out
> that development is meaningless without testing.  Unless the product
> being developed is documentation and testing is accomplished by reading
> the document as formatted by a browser, your users are going to want to
> be able to compile and run whatever they are making.  Will your web
> platform provide that too?  It's not totally out of the question, and
> I've seen submit-your-code-and-we'll-run-it stuff before.  I'm just
> saying that there's a lot to consider before you reach the point that
> what you've put together is actually useful.
> 
>> I hear what you’re saying about no way to edit without command line,
>> but actually it would be perfectly fine to have the check out dir tree
>> accessible via SMB share..  Then they can edit the files over SMB.
>> But without command line access there is no way for them to commit the
>> changes into fossil.  That’s where a Web UI for some of those commands
>> would be useful.
> 
> I would strongly advise against SMB over the public Internet.  VPN may
> work, also you can use SMB within the firewalls of your organization.
> Basically you're sidestepping the requirement to provide a web interface
> to file management and editing, which is fine.  Just, like I said above,
> remember that not only do you have to have file management/editing and
> access to Fossil commands, but you also need to be able to build and
> test whatever is being developed.  The requirements snowball the more
> you think about them.
> 
>> But this could also be useful even when running fossil alone on a
>> local desktop machine.  Kind of like when you run “fossil ui” and up
>> pops a web interface to the fossil repo on the local machine.  Still
>> edit the files with vi, etc, but the fossil UI basically accesses the
>> DB right now…it doesn’t touch any checked out dir trees or provide any
>> way to use the UI to do stuff on them….
> 
> Okay, now we're agreeing on something.  The web interface has limited
> cognizance of the checkout in which it is being run.  It can highl

Re: [fossil-users] web UI for a working checkout?

[Steve Schow]

> On Sep 29, 2017, at 2:46 PM, Andy Goth  wrote:
>> 
> 
> http://chiselapp.com/ comes closest in that it provides a web interface
> for working on repositories as a whole.  It does not provide what you
> ask, nor do I know of any other web platforms that do.


Hey thats pretty cool, I was not even aware of that site!  I am going to check 
that out, I guess that’s a decent way to keep a repo public, then I can clone 
it here locally for working on stuff.  But that webui just looks pretty much 
like the same one built into the fossil binary, yes?Who is hosting that and 
what is the longevity compared to github and others?


> 
> The trouble is that in order for a checkout user interface to be
> meaningful, it needs to be bundled with tools to actually edit the
> checkout files.  Otherwise there's little point.  From the perspective
> of most programmers, web browsers can't compete with dedicated text
> editors, so what you describe will likely not be successful in targeting
> programmers.


Primary interest right now is in using a headless machine that will be hosting 
a repo.  And often users will not have command line access either.   In the 
simplest case, I could set it up, with web ui access to the repo itself, but 
then always require them to clone the repo on another machine and do all their 
edits there and push their changes back to remote master repo.  But it turns 
out there is also a use case for them being able to add files and commits to 
the repo directly on the headless linux box without having to clone the repo to 
another client machine.

I hear what you’re saying about no way to edit without command line, but 
actually it would be perfectly fine to have the check out dir tree accessible 
via SMB share..  Then they can edit the files over SMB.  But without command 
line access there is no way for them to commit the changes into fossil.  That’s 
where a Web UI for some of those commands would be useful.

But this could also be useful even when running fossil alone on a local desktop 
machine.  Kind of like when you run “fossil ui” and up pops a web interface to 
the fossil repo on the local machine.  Still edit the files with vi, etc, but 
the fossil UI basically accesses the DB right now…it doesn’t touch any checked 
out dir trees or provide any way to use the UI to do stuff on them….which is 
what I wish it could..then it could be a fairly platform independent checkout 
GUI….including over to headless linux boxes that might have a check out there 
also.

> 
> One thing that could happen is for "fossil ui" itself to get more
> checkout functionality, since it does indeed get used in combination
> with checkout editing.  Since it's used in conjunction with the command
> line, it does not make any effort to replace the command line.  But that
> doesn't mean it can't be an alternative interface, just like how it
> provides an alternative to diffing historical files from the command line.
> 


The key is that it would have to become aware of specific dirs which have 
checkouts in them and then provide a view of that checkout..including 
uncommitted changes, etc..



> Personally I'm not interested in "fossil ui" performing the checkout
> manipulations you describe, but nevertheless I would like it to be a bit
> more aware of checkouts, e.g. to diff the current checkout with its
> baseline check-in or other versions, to show the list of changes, or to
> show and manage stashes.


Right, well it would be great if we could see what exactly is GOING to be 
changed if we decide to commit, for example.  Compare the working files in the 
checkout dir against what is in the DB…etc, etc..  those are just some of the 
simplest cases..

Ultimately I guess I will have to roll out my own, as I don’t think anything 
exists and I doubt there is much interest.  I have a use case in the short term 
for something very simple that can at least just commit file changes to the 
repo through a webui.  Basically need to be able to point the web ui at a 
.fslckout db and then enable the user to call commit, update, branch and a few 
other simple things.  Having a file tree view of the actual dir tree would be 
useful too.  Actually editing the files through the web, as you suggest, I 
don’t think would be that interesting to most people, but never know.I’d 
personally love to see an editor that could display a diff in realtime as I 
edit the file, so that as I edit the file I can see highlighting to show what I 
have changed compared to what is the repo, for example.  Just one strange idea… 
 but that  isn’t the primary goal I’m asking for now just mainly want to be 
able to commit, update, changes, branch or a few basic operations against a 
.fslchkout where files have been updated over SMB somehow.



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

[fossil-users] web UI for a working checkout?

[Steve Schow]

Is anyone aware of any Web based ui for working with a working checkout?  I’m 
looking for the ability to have a web app that can basically execute things 
like commit, branch, update and other checkout related fossil commands, 
operating on a checkout directory tree located on the webserver of course…


___
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] wiki in ticket comments??

[Steve Schow]

well figured it out..  for some reason my main repository had the following 
options enabled in Admin:Configuration

Use HTML as wiki markup language

I’m not sure why it was enabled.   Turned it off and enumeration works fine now.

its unfortunate, I think maybe I had that on because I have some wiki pages 
that use some embedded graphics and I think I had to turn that on and use HTML 
or something to in order to properly format my wiki page.  But apparently that 
forces the ticket comments to also use HTML instead of wiki…  Is there a way to 
display pictures on wiki pages done with pure wiki markup?

Actually yea, a wiki page I had with a nice diagram on it, now doesn’t show the 
diagram, only a little icon in its place, so I guess something about that 
setting enabled me to make a nice wiki page, but I’d rather have enumeration 
lists in ticket comments…  is it possible to have a diagram on my wiki page 
without that HTML option checked?





> On Aug 15, 2017, at 5:34 PM, Steve Schow <st...@bstage.com> wrote:
> 
> hmm, I created a new repository and works fine there…very strange..  
> 
> 
>> On Aug 15, 2017, at 5:09 PM, Warren Young <war...@etr-usa.com> wrote:
>> 
>> On Aug 15, 2017, at 4:46 PM, Steve Schow <st...@bstage.com> wrote:
>>> 
>>> i’m getting the same result with new tickets, or adding on to tickets, 
>>> makes no difference.
>> 

___
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] wiki in ticket comments??

[Steve Schow]

hmm, I created a new repository and works fine there…very strange..  


> On Aug 15, 2017, at 5:09 PM, Warren Young <war...@etr-usa.com> wrote:
> 
> On Aug 15, 2017, at 4:46 PM, Steve Schow <st...@bstage.com> wrote:
>> 
>> i’m getting the same result with new tickets, or adding on to tickets, makes 
>> no difference.
> 
> Send back the changed repository so that I (or someone else) can examine it.
> ___
> 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] wiki in ticket comments??

[Steve Schow]

i’m getting the same result with new tickets, or adding on to tickets, makes no 
difference.

I can see that last year when I was using fossil more actively I created some 
tickets with enumerated lists, but I can’t recall how I actually did it.  its 
possibly i had to use HTML directly I vaguely recall having some trouble with 
this before also…  but I’d rather not have to use HTML if possible.


> On Aug 15, 2017, at 4:28 PM, Warren Young <war...@etr-usa.com> wrote:
> 
> On Aug 15, 2017, at 4:23 PM, Steve Schow <st...@bstage.com> wrote:
>> 
>> I have tried with a blank line between the paragraph and the list also, same 
>> result.  yes I am making sure always that the wiki menu item is selected
> 
> Here’s a freshly-created Fossil repository with one ticket, formatted as you 
> ask:
> 
>https://drive.google.com/open?id=0B6JrNPgaCV7RYldEc0d6MnpXTGc
> 
> What happens if you add a new ticket to that repository, or add a new comment 
> on my test ticket?
> ___
> 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] wiki in ticket comments??

[Steve Schow]

I have tried with a blank line between the paragraph and the list also, same 
result.  yes I am making sure always that the wiki menu item is selected


> On Aug 15, 2017, at 4:15 PM, Warren Young <war...@etr-usa.com> wrote:
> 
> On Aug 15, 2017, at 4:12 PM, Steve Schow <st...@bstage.com> wrote:
>> 
>> yes the wiki menu item is selected
>> 
>> yes no blank lines are present, still getting unformatted results.  for 
>> example
>> 
>> This is some paragraph
>>  #  item one
>>  #  item two
>> 
>> this results in:
>> 
>> This is some paragraph # item one # item two
> 
> By “no breaks” I meant between the list items.  You still need them between 
> normal paragraphs.
> 
> Also, realize that when adding new comments to an existing ticket, the 
> formatting mode for the new comment will be “[links only]” by default unless 
> you have customized the ticket system to override that.  By default, if you 
> want new comments to be Wiki, you have to enable it each time.
> 
> I tested this before sending my prior reply.  I got it to behave the way you 
> say you want in a new ticket I had to file locally anyway.
> ___
> 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] wiki in ticket comments??

[Steve Schow]

yes the wiki menu item is selected

yes no blank lines are present, still getting unformatted results.  for example

This is some paragraph
  #  item one
  #  item two

this results in:

This is some paragraph # item one # item two


> On Aug 15, 2017, at 4:02 PM, Warren Young <war...@etr-usa.com> wrote:
> 
> On Aug 15, 2017, at 3:55 PM, Steve Schow <st...@bstage.com> wrote:
>> 
>> no matter what I have tried to add enumeration lists in my fossil tickets, 
>> the ticket comment is still coming up without any formatting.
> 
> There are two ways I can see that happening:
> 
> 1. You didn’t select Wiki from the “Format” drop-down. The default 
> “links-only” format doesn’t format numbered lists the way you want.
> 
> 2. Wiki formatting doesn’t allow spaces between paragraphs.  They have to 
> butt up against each other:
> 
>  #  Item 1
>  #  Item 2
> 
> This is ugly when the items have long lines, but it’s a limitation of wiki 
> formatting.
> 
> This is one reason I want Markdown as a formatting option in tickets.
> ___
> 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

[Steve Schow]

warren you are being very aggressive towards me I’m not sure why.  I’ve asked 
for some ideas for work arounds and so far none of the work arounds are really 
acceptable for various reasons.  No offense is intended.  Relax man!


> On Aug 15, 2017, at 4:06 PM, Warren Young <war...@etr-usa.com> wrote:
> 
> On Aug 15, 2017, at 3:58 PM, Steve Schow <st...@bstage.com> wrote:
>> 
>> if each script file has its own independent version, its not part of a 
>> greater whole per say…its just the version of that exact file..nothing 
>> more……appearing in the source comment.
> 
> My ship script doesn’t care about “greater wholes”.  It extracts the same 
> info from Fossil that RCS, CVS, or Subversion would have given with the 
> $Revision$ keyword.  And with a sed call, you could even substitute it into 
> the file text.
> 
> Whatever.  Use it or not.  I wanted to get the two key fossil commands 
> embedded into that script out into the world anyway.
> 
>> not once did I demand that anyone make any modifications to fossil. 
> 
> Only implicitly by shooting down all the alternatives you been given.
> ___
> 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] fossil ticket comments - wiki markup?

[Steve Schow]

no matter what I have tried to add enumeration lists in my fossil tickets, the 
ticket comment is still coming up without any formatting.

I read that in order to add an enumeration list I just have to put “#” 
surrounded by two spaces..  But that just ends up with a totally unformatted 
ticket comment that has no blank lines or line breaks and a # sign in there 
instead of an enumerated list.  what is the secret to making somewhat formatted 
ticket comments, including enumerated lists?
___
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

[Steve Schow]

uhmmm, not once did I demand that anyone make any modifications to fossil.  I 
asked if it can do it, and if not, what are some work arounds.  


> On Aug 15, 2017, at 3:55 PM, Warren Young <war...@etr-usa.com> wrote:
> 
> On Aug 15, 2017, at 3:50 PM, Steve Schow <st...@bstage.com> wrote:
>> 
>> its way overkill to have to follow any kind of build or deployment process 
>> whatsoever for these scripts.  
> 
> One other thing: you had to have some kind of step to deploy these.  If it’s 
> just a “cp” command, build that into a modified version of my ship script.  
> Now you’ve just exchanged one command — which you had to give anyway — for 
> another.
> 
> The alternative you’ve been demanding is that someone else do a whole bunch 
> of modifications to Fossil which the vast majority of the user base won’t 
> want to use, either out of lack of need or out of philosophic disagreement.  
> Talk about overkill.
> ___
> 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

[Steve Schow]

Thanks Warren.  I’m pretty handy with sed and awk and all the rest.  I’m just 
trying to figure out the best way to work out an automatic workflow for having 
a version in the source comment.

wrapper scripts around fossil that do this sort of thing might work, but see if 
each script file has its own independent version, its not part of a greater 
whole per say…its just the version of that exact file..nothing more……appearing 
in the source comment.  

Honestly, its probably just easier to remember to manually update it before 
committing and never forget, but I hate manual anything.  having a seperate 
script that brings something in from another file is always a possibility but 
if every file has its own verison…then what…a seperate version file for every 
js file?  starts to get kind of ridiculous…




> On Aug 15, 2017, at 3:52 PM, Warren Young <war...@etr-usa.com> wrote:
> 
> On Aug 15, 2017, at 3:50 PM, Steve Schow <st...@bstage.com> wrote:
>> 
>> I will try to find a solution outside of fossil.
> 
> The ship script gets you 95% of the way there.
> 
> For example, if you absolutely positively had to have the version number 
> embedded into the deployed JS file, you could substitute it into the shipped 
> JS file with a few lines of modifications to my script.
> 
> Basically, swap the zip call for a call to sed.
> ___
> 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] wiki in ticket comments??

[Steve Schow]

no matter what I have tried to add enumeration lists in my fossil tickets, the 
ticket comment is still coming up without any formatting.

I read that in order to add an enumeration list I just have to put “#” 
surrounded by two spaces..  But that just ends up with a totally unformatted 
ticket comment that has no blank lines or line breaks and a # sign in there 
instead of an enumerated list.  what is the secret to making somewhat formatted 
ticket comments, including enumerated lists?

___
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

[Steve Schow]

I’m glad to hear it only took you half an hour to write the script, but again, 
its way overkill to have to follow any kind of build or deployment process 
whatsoever for these scripts.  

Thanks all for the helpful feedback, I will try to find a solution outside of 
fossil.


> On Aug 15, 2017, at 3:37 PM, Warren Young <war...@etr-usa.com> wrote:
> 
> On Aug 15, 2017, at 3:07 PM, Steve Schow <st...@bstage.com> wrote:
>> 
>> yea that’s way overkill.
> 
> The attached script creates versioned zip files given a Fossil-versioned file 
> name containing the file and a manifest file called VERSION.  You can 
> therefore get the version number in the file name and in the VERSION file.
> 
> Time to develop: under half an hour, including testing.
> 
>> Creating deployment steps for each and every one of them is not a practical 
>> solution.
> 
> The attached script is a wrapper for zip(1).  Unless “deployment” means “copy 
> file directly out of Fossil into the production tree” you needed something 
> like this anyway.
> 
> 
> ___
> 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

[Steve Schow]

yea that’s way overkill.  As I said earlier, these are entirely independent 
scripts, they are not parts of a greater whole.  Creating deployment steps for 
each and every one of them is not a practical solution.


> On Aug 15, 2017, at 2:58 PM, Warren Young <war...@etr-usa.com> wrote:
> 
> On Aug 15, 2017, at 2:53 PM, Steve Schow <st...@bstage.com> wrote:
>> 
>> well…its not for a website…javascript is used for a lot of stuff out there 
>> besides the web.  Its not practical for the name of the file to have a 
>> version encoded into it.
> 
> Easily solved.  During the “generate deployment package” step, create a 
> manifest file that maps file names to Fossil checkin IDs.  Ship the manifest 
> along with the checked-out files.
> ___
> 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

[Steve Schow]

well…its not for a website…javascript is used for a lot of stuff out there 
besides the web.  Its not practical for the name of the file to have a version 
encoded into it.




> On Aug 15, 2017, at 2:25 PM, Warren Young <war...@etr-usa.com> wrote:
> 
> On Aug 15, 2017, at 12:09 PM, Steve Schow <st...@bstage.com> wrote:
>> 
>> I’m hoping to have a version that is stamped into the comments of the actual 
>> file as well.  For example I have some javascripts that are used in another 
>> entirely closed environment that doesn’t have access to fossil, so it would 
>> be nice to be able to know which version of the script is being used
> 
> You’re doing it wrong.
> 
> What you actually want to do here is bake some unique prefix of the Fossil 
> checkin ID for each .js file into the *distributed file name*.  Say the first 
> 8 characters: js/my-script-ABC123CD.js.  Then you build a map from 
> “js/my-script.js” to the generated file name and substitute it in as part of 
> the build steps.
> 
> This allows you to set the web server’s cache expiry time for *.js to 
> something like “now plus 20 years”, since the file name changes every time 
> the file *content* changes.
> 
> You already need a build system for a web site so you can do linting, 
> minification, and file merging.  All I’m suggesting is that if js/*.js turns 
> into js/all.min.js now that you modify that process so it generates 
> js/all.ABC123CD.js where the version tag is based on the latest Fossil 
> checkin ID for all of js/*.js.
> 
> The latest checkin ID for each file is easily extracted from “fossil finfo” 
> output.  There’s only one trick to it: you have to filter out checkin 
> messages that refer to branches you are not currently on.  If someone checks 
> something in on the development branch but you’re building from a stable 
> branch, you don’t want the dev branch checkin ID in the file name, you want 
> the newest checkin ID for that file *on the stable branch*.  If you’re on a 
> POSIX platform, that restriction is easy provided by a single grep call.
> 
> I’ve got all of that solved here, but I can’t share it due to it being part 
> of a closed-source system.  But, you probably don’t want my solution exactly, 
> since it was created before we had all-in-one JS minify/verify/merge tools:
> 
>
> https://stackoverflow.com/questions/9287823/combine-and-minify-multiple-css-js-files
> 
> So, pick one of those tools, then rename the resulting CSS or JS file 
> according to its latest checkin on the working branch in a subsequent build 
> step.  Save that file name mapping somewhere and substitute that file name 
> into the generated HTML somehow.  That latter step is trivial if this site is 
> backed by something that dynamically generates HTML anyway.
> 
> If you aren’t dynamically generating your HTML already, look into the many 
> static HTML generation tools:
> 
>https://www.staticgen.com/
> 
> That gets you a build-and-publish model, into which you can substitute the 
> generated CSS and JS file names.
> 
>> what I miss about RCS, is it would bump up the RCS number and could 
>> substitute that into the source for me during checkout.
> 
> There’s a reason keyword expansion was disabled by default in Subversion, and 
> why the later DVCSes haven’t either not replicated the feature or followed 
> Subversion’s lead.
> 
> If you go Googling, you’ll find lots of “not recommended,” “feature of last 
> resort,” etc.
> 
> Please give up on this misfeature.  There are better ways.
> ___
> 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

[Steve Schow]

Interesting, it still works for you because you have a source file and “built” 
file…  with scripts its sorta redunant to require a built file, but some of you 
are starting to convince me that I may have to create that kind of procedure, 
always use make on everything and only distribute what is in the the “build” 
dir after inserting version info however I want.

another thing I am thinking about doing, just thinking out loud here, is 
combining RCS with fossil just to get the auto file versioning, because I also 
like to have intermediate versions without commiting every little thing to the 
repository.  So for example, I could take a file that is already in the fossil 
checkout, and work on it a bit.  check it in and out of RCS (locally), do that 
a few times…each time its bumping up the version number for me.  When I’m ready 
to make a single commit to fossil then the version will already be manually 
updated by RCS and as well I will have those local versions to go back to in 
between commits if I want to.  

or I could just make sure to manually update the version number before commit 
and get in the habit.   Seems like at my old job with clearcase we had to 
manually update version numbers in the source, but I can’t remember now its 
been a while.



> On Aug 15, 2017, at 1:42 PM, j. van den hoff <veedeeh...@gmail.com> wrote:
> 
> On Tue, 15 Aug 2017 19:57:34 +0200, Steve Schow <st...@bstage.com> wrote:
> 
>> Related to this question, anyone have any workflow suggestions for 
>> accomplishing this aside from remembering to bump the number manually in the 
>> file before every important checkin or commit?
> 
> my workaround is roughly like this:
> 
> put an invariant `include' directive into your source file where the included 
> file (called, e.g., `version') is a) not tracked by fossil and b) contains 
> the current hash as delivered by `fossil info'. under linux/unix/macosx I 
> specifically use
> 
> fossil info|awk '/^checkout/{print substr($2,1,10)}'
> 
> to  get the hash itself.
> 
> I update the `version' file during the make run. personally, I am using this 
> approach not so much with source code but mostly with LaTeX or AsciiDoc 
> documents where I want the version info in the formatted (pdf or html) 
> output. works just fine. (actually I also check that `fossil changes' does 
> not report anything. otherwise I add a trailing `+' to the hash indicating 
> that the document is currently not yet checked in). of course the temporary 
> file (`version') might be avoided if instead of the `include' some sort of 
> `exec' of a subprocess is available directly substituting the hash into a 
> variable.
> 
> hth
> joerg
> 
>> 
>> 
>>> On Aug 15, 2017, at 11:46 AM, Stephan Beal <sgb...@googlemail.com> wrote:
>>> 
>>> 1) no.
>>> 
>>> 
>>> 1 - Is there any way to embed a substitution parameter into a source file 
>>> that Fossil can replace with version info at time of checkin?  (similar to 
>>> RCS).
>>> 
>>> thanks
>> 
> 
> 
> -- 
> Using Opera's revolutionary email client: http://www.opera.com/mail/

___
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

[Steve Schow]

right..  so what you’re saying is once a file is added, its permanently checked 
out basically, and any changes you make to the file are pending a commit.



> On Aug 15, 2017, at 1:10 PM, Stephan Beal  wrote:
> 
> Nope - that's git's way of doing it (this is why i thought you were using git 
> as a basis for comparison!). In fossil "add" is a one-time thing which is 
> only necessary one time (ever) per file. (In git "add" is needed to "stage" 
> the file for the next commit.) After a file is added, you use "checkin" to 
> irrevocably commit those changes (along with any number of other changes) to 
> fossil. There is no intermediary step of "pending for the next commit" in 
> fossil. Contrariwise, any changes made in a checked-out copy are always 
> considered "pending for the next commit" (for lack of a better phrase) until 
> they are either committed or discarded (the checkout is deleted, "close"d, or 
> otherwise revered to a pristine state).
> 
> -- 
> - 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

[Steve Schow]

by the way, I don’t really use git much other then bare minimum to save 
something on github, so please don’t explain anything in terms of git concepts, 
I won’t understand you.

I used RCS and SCCS a lot in the past.

In RCS, you have to explicitly checkout a file to edit it, locking it out from 
anyone else changing it until you check it back in.  I understand that fossil 
doesn’t checkout files exclusively that way.  In fossil we use “add” which 
includes the file to a set of files that will be commited in the next commit.  
We can edit away, the file is not really “checked out” per say, like it is in 
RCS and SCCS.  Its just flagged for the next commit.  We make changes and run 
commit and then at that point its just a file in the filesystem…fossil may be 
able to tell us it has changed…but its not part of the next commit list until 
we add it again.  right?



> On Aug 15, 2017, at 12:48 PM, Stephan Beal <sgb...@googlemail.com> wrote:
> 
> On Tue, Aug 15, 2017 at 8:43 PM, Steve Schow <st...@bstage.com 
> <mailto:st...@bstage.com>> wrote:
> So one quick question…is a hash created only during commit?   doesn’t happen 
> yet during “add” right?
> 
> The hash is calculated during the commit and includes (among many other 
> things) the timestamp of the commit in its calculation. Thus a commit of the 
> exact same information at two points in time (milliseconds-precision, if i'm 
> not mistaken) are guaranteed to have two different hashes.
>  
>  I always forget, when you’re talking about “checkin” are you referring to 
> stuff that has been added or stuff that has been committed?
> 
> git distinguishes between those in a different way than fossil does. In 
> fossil "add" is kind of like RCS, CVS, and SVN understand "add", and very 
> much NOT how git understands "add". 
>  
> I hear what you’re saying that, if I commit a file to get the hash, then 
> update the source to have the new hash, the file then appears as having been 
> “changed”.  Its not clear to me it would continue to be part of the next 
> checkin though unless it is added again?
> 
> That's git terminology - fossil doesn't work that way.
>  
> Its just that the file in place would be showing as having changed compared 
> to the repository, due to the version being updated in there.  
> 
> Correct. "fossil changes" would list that file as changed.
> 
> -- 
> - stephan beal
> http://wanderinghorse.net/home/stephan/ 
> <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

[Steve Schow]

Yea I wasn’t meaning to say RCS is better, or I would be using it.  I’m using 
fossil because it is so complete and a variety of reasons is far surpasses RCS. 
 Just saying I miss that feature and looking for a work around.  That 
particular feature of RCS is very handy for situations where you have 
standalone scripts or things that are updated often and distributed.  Aside 
from manually updating a number right before commit, I don’t know how else I 
could keep track of what versions of the script are floating around.  IN a 
larger project where you have one big release, it makes sense to use a master 
version file and bake it into binaries, etc..  but for scripts..well..sure…I 
could have a make step to always build scripts into distributed scripts that 
have versions baked in somehow…but that is a pain when you’re talking about a 
lot of totally independent scripts that are updated often and independently of 
each other.

So one quick question…is a hash created only during commit?   doesn’t happen 
yet during “add” right?  I always forget, when you’re talking about “checkin” 
are you referring to stuff that has been added or stuff that has been 
committed?  I forget what is the notion of “checkout" or “checkin" in fossil.  
Time to go re-learn some concepts again….

I hear what you’re saying that, if I commit a file to get the hash, then update 
the source to have the new hash, the file then appears as having been 
“changed”.  Its not clear to me it would continue to be part of the next 
checkin though unless it is added again?  Its just that the file in place would 
be showing as having changed compared to the repository, due to the version 
being updated in there.  




> On Aug 15, 2017, at 12:18 PM, Stephan Beal <sgb...@googlemail.com> wrote:
> 
> 
> 
> On Tue, Aug 15, 2017 at 8:09 PM, Steve Schow <st...@bstage.com 
> <mailto:st...@bstage.com>> wrote:
> well I’m hoping to have a version that is stamped into the comments of the 
> actual file as well. 
> 
> Stamping that version would change the hash. To the best of my knowledge that 
> feature cannot be implemented with DVCS (which requires hashing (non-serial 
> IDs) for versioning).
>  
> For example I have some javascripts that are used in another entirely closed 
> environment that doesn’t have access to fossil, so it would be nice to be 
> able to know which version of the script is being used…with many updates 
> happening in early stages of development, its easy to forget to manually 
> update a comment with a number.
> 
> For those types of things you've got to "build" a version of those scripts, 
> injecting the current version number.
>  
>   what I miss about RCS, is it would bump up the RCS number and could 
> substitute that into the source for me during checkout.
> 
> But RCS was missing about 99% of the features of a modern DVCS (and RCS 
> didn't have the "D" at all).
>  
> It sounds like what I would need to do is keep a seperate db that associates 
> hashes with version numbers and then use a wrapper script or something to do 
> this work of substituting that into the source comment.  yes?
> 
> Right. But the moment you do that, you change the hashes of those files, 
> making them completely different content as far as any DVCS is concerned.
> 
> -- 
> - stephan beal
> http://wanderinghorse.net/home/stephan/ 
> <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

[Steve Schow]

well I’m hoping to have a version that is stamped into the comments of the 
actual file as well.  For example I have some javascripts that are used in 
another entirely closed environment that doesn’t have access to fossil, so it 
would be nice to be able to know which version of the script is being used…with 
many updates happening in early stages of development, its easy to forget to 
manually update a comment with a number.  what I miss about RCS, is it would 
bump up the RCS number and could substitute that into the source for me during 
checkout.  I guess since fossil doesn’t number versions that way…just uses 
hashes…there is no way to have fossil do that.  Just wondering if anyone else 
has any other workflow suggestions for how to automatically embed a bumped up 
version number with each checkin into a comment of the source itself..

It sounds like what I would need to do is keep a seperate db that associates 
hashes with version numbers and then use a wrapper script or something to do 
this work of substituting that into the source comment.  yes?


> On Aug 15, 2017, at 12:03 PM, Richard Hipp <d...@sqlite.org> wrote:
> 
> On 8/15/17, Steve Schow <st...@bstage.com> wrote:
>> Related to this question, anyone have any workflow suggestions for
>> accomplishing this aside from remembering to bump the number manually in the
>> file before every important checkin or commit?
> 
> Fossil is self-hosting on Fossil.  The way it works is that there is a
> "VERSION" file at the top-level that contains the current project
> version number as text.  This version number gets baked into the
> binary by the makefile.  We manually edit the "VERSION" file prior to
> each release.
> 
>https://www.fossil-scm.org/fossil/finfo?name=VERSION
> 
> The "version number" of individual files is inherent in its SHA3 hash
> (or SHA1 historically).  If you have some file and you want to ask
> "what check-in does this file go with" you can type:
> 
>fossil whatis $HASHPREFIX
> 
> And Fossil will tell you about that file - when it was first checked
> in, etc.  To compute a SHA3 hash on an unknown file:
> 
>fossil sha3sum $FILENAME
> 
> 
> -- 
> 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] Two easy questions

[Steve Schow]

ah…  I dont’ think I had any checkouts happening at that point…well maybe I 
have forgotten what a checkout is.  I haven't used fossil in about a year.  
Sounds like “pull” is what I needed to do…which update accomplished for me 
anyway I guess, but I need to go re-read about the checkin/checkout paradigm to 
make sure in the future I’m not messing anything up if I use update.

thanks for the explanation.


> On Aug 15, 2017, at 11:58 AM, Richard Hipp  wrote:
> 
> On 8/15/17, Stephan Beal  wrote:
>> Sync doesn't modify the checkout. Use update for that.
>> 
>> - stephan
>> Sent from a mobile device,. Please excuse brevity...
> 
> I am on a laptop so I can say more :-)
> 
> In Fossil, your "repository" and your "checkout" are separate.  The
> repository stores all history of your project.  The checkout only
> holds whatever version you are currently working on.  The checkout is
> linked to the repository, and is based on a specific "checkin" (a.k.a
> "commit") within the repository, possibly with local edits.  Fossil is
> different from most other VCSes in that it allows you to have multiple
> checkouts per repository.  With git and hg, your repository and
> checkout are more closely bound and are strictly one-to-one.
> 
> The "sync", "push", and "pull" commands only touch the repository.
> They do nothing to the checkout.
> 
> The "update" command is used to move your checkout to the latest code
> (or to an historical version of the code, depending on what options
> you use).  By default, the "update" command first runs "pull" to make
> sure that your local repository is up-to-date with the latest changes
> on the server.  But the "pull" command does *not* automatically run an
> "update".
> 
> -- 
> 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] Two easy questions

[Steve Schow]

Related to this question, anyone have any workflow suggestions for 
accomplishing this aside from remembering to bump the number manually in the 
file before every important checkin or commit?


> On Aug 15, 2017, at 11:46 AM, Stephan Beal  wrote:
> 
> 1) no.
> 
> 
> 1 - Is there any way to embed a substitution parameter into a source file 
> that Fossil can replace with version info at time of checkin?  (similar to 
> RCS).
> 
> thanks

___
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

[Steve Schow]

when say nothing is hurt by it…its totally and completely safe to run 
rebuild…nothing will be lost?  If so I will do it just in case.

By the way, update worked, thanks.  Silly me…I vaguely remember that now.  
Silly me for going so long without coding anything…

I guess sync brings in the wiki and tickets right?

> On Aug 15, 2017, at 11:52 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> 
> Rebuild is rarely needed but never hurts. Fossil will tell you if it thinks a 
> rebuild might be required.
> 
> - stephan
> Sent from a mobile device, possibly from bed. Please excuse brevity, typos, 
> and top-posting.
> 
> On Aug 15, 2017 19:48, "Steve Schow" <st...@bstage.com 
> <mailto:st...@bstage.com>> wrote:
> I did upgrade them all to 2.3, but I didn’t do rebuild.  Do I need to do that?
> 
>> On Aug 15, 2017, at 11:46 AM, Stephan Beal <sgb...@googlemail.com 
>> <mailto:sgb...@googlemail.com>> wrote:
>> 
>> 1) no.
>> 
>> 2) make sure all of your systems have been upgraded to compatible versions 
>> (v2) and that you run "fossil rebuild" on each after upgrading. That might 
>> not solve what you're seeing, but it's a good place to start.
>> 
>> ----- stephan
>> Sent from a mobile device, possibly from bed. Please excuse brevity, typos, 
>> and top-posting.
>> 
>> On Aug 15, 2017 19:41, "Steve Schow" <st...@bstage.com 
>> <mailto:st...@bstage.com>> wrote:
>> Its been a while since I used Fossil, getting back to it, and have two quick 
>> easy questions.
>> 
>> 1 - Is there any way to embed a substitution parameter into a source file 
>> that Fossil can replace with version info at time of checkin?  (similar to 
>> RCS).
>> 
>> 2 - I previous setup my fossil system with 4 machines, one machine running 
>> as web server to handle ticketing and wiki as well as me kind of the master 
>> repository.  Then the other 3 machines sync off that machine.  So I have 3 
>> backups.  Fine so far.  It was working great last year.  Today I tried to 
>> check something in to the master repository, but even after going to one of 
>> the others and running fossil sync, the change doesn’t show up there…am I 
>> forgetting something?
>> 
>> thanks
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org <mailto:fossil-users@lists.fossil-scm.org>
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 
>> <http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org <mailto:fossil-users@lists.fossil-scm.org>
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 
>> <http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users>
> 
> 
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org <mailto:fossil-users@lists.fossil-scm.org>
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 
> <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] Two easy questions

[Steve Schow]

I did upgrade them all to 2.3, but I didn’t do rebuild.  Do I need to do that?

> On Aug 15, 2017, at 11:46 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> 
> 1) no.
> 
> 2) make sure all of your systems have been upgraded to compatible versions 
> (v2) and that you run "fossil rebuild" on each after upgrading. That might 
> not solve what you're seeing, but it's a good place to start.
> 
> - stephan
> Sent from a mobile device, possibly from bed. Please excuse brevity, typos, 
> and top-posting.
> 
> On Aug 15, 2017 19:41, "Steve Schow" <st...@bstage.com 
> <mailto:st...@bstage.com>> wrote:
> Its been a while since I used Fossil, getting back to it, and have two quick 
> easy questions.
> 
> 1 - Is there any way to embed a substitution parameter into a source file 
> that Fossil can replace with version info at time of checkin?  (similar to 
> RCS).
> 
> 2 - I previous setup my fossil system with 4 machines, one machine running as 
> web server to handle ticketing and wiki as well as me kind of the master 
> repository.  Then the other 3 machines sync off that machine.  So I have 3 
> backups.  Fine so far.  It was working great last year.  Today I tried to 
> check something in to the master repository, but even after going to one of 
> the others and running fossil sync, the change doesn’t show up there…am I 
> forgetting something?
> 
> thanks
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org <mailto:fossil-users@lists.fossil-scm.org>
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 
> <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] Two easy questions

[Steve Schow]

Well slight correction to question 2.  After I ran sync, if I use “fossil ui” 
on the local machine, the web interface there on the local remote machine does 
show the checkin that was made on the other master repository…., but looking at 
my file system where its supposed to be…its not there.

> On Aug 15, 2017, at 11:41 AM, Steve Schow <st...@bstage.com> wrote:
> 
> Its been a while since I used Fossil, getting back to it, and have two quick 
> easy questions.
> 
> 1 - Is there any way to embed a substitution parameter into a source file 
> that Fossil can replace with version info at time of checkin?  (similar to 
> RCS).
> 
> 2 - I previous setup my fossil system with 4 machines, one machine running as 
> web server to handle ticketing and wiki as well as me kind of the master 
> repository.  Then the other 3 machines sync off that machine.  So I have 3 
> backups.  Fine so far.  It was working great last year.  Today I tried to 
> check something in to the master repository, but even after going to one of 
> the others and running fossil sync, the change doesn’t show up there…am I 
> forgetting something?
> 
> thanks
> ___
> 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] Two easy questions

[Steve Schow]

Its been a while since I used Fossil, getting back to it, and have two quick 
easy questions.

1 - Is there any way to embed a substitution parameter into a source file that 
Fossil can replace with version info at time of checkin?  (similar to RCS).

2 - I previous setup my fossil system with 4 machines, one machine running as 
web server to handle ticketing and wiki as well as me kind of the master 
repository.  Then the other 3 machines sync off that machine.  So I have 3 
backups.  Fine so far.  It was working great last year.  Today I tried to check 
something in to the master repository, but even after going to one of the 
others and running fossil sync, the change doesn’t show up there…am I 
forgetting something?

thanks
___
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] Automatic Ticket-commit tagging

[Steve Schow]

Can you please show me where I can find version history of the ticket report 
SQL statement?  I have been copy and pasting this into a text file in order to 
get versioning on it…but if fossil is versioning it already then I don’t need 
to, but I was not able to see any way to do that.



On May 22, 2016, at 6:52 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:

> On 5/22/2016 3:53 PM, Steve Schow wrote:
>> I’m sorry I’m not seeing anywhere that ticket “reports” are contained as 
>> versioned artifacts…
> 
> Ticket reports are formatted the same as changes.
> 
> -- 
> Andy Goth | 
> 
> ___
> 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] possible to change checkin?

[Steve Schow]

Ok, so if I have this straight…  the simple answer is “no”.  Fossil is, by 
design, not going to let me modify a checkin once it has gone into the DB, fair 
enough..

I’m not aware of this reparent fork…are you saying that is a fork of fossil 
itself that lets us cheat a little?

I’m not really rejecting anything…but generally…its not going to be worth it to 
me to move the checkin to a branch which will be closed and left hanging around 
forever with the unmerged change in it every time this mistake happens.

At that points its just better to leave the two file changes in one 
checkin…even though I am associating the checkin with a ticket and one of the 
file changes has nothing to do with that ticket, etc.  Kind of annoying, but 
once its in…its in…and on the surface, unless I’m misunderstanding, it might be 
possible to use this fork of fossil to reverse out the checkin so its not left 
dangling in an orphaned branch…though…generally….I would probably rather stick 
to vanilla fossil.  

And no I have no desire to tamper with artifacts.  I was just asking if fossil 
has any way to correct this kind of mistake.  I think the simple asnwer is “no, 
be more careful”


On May 22, 2016, at 6:43 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:

> On 5/22/2016 3:52 PM, Steve Schow wrote:
>> Let’s say I have added file A…then never commit it…
>> 
>> a couple days later I add file B and hit commit
>> 
>> Suddenly I realize that two files were committed.  I want them both
>> commited, but I want them committed as seperate checkins.
>> 
>> I can move the one checkin to a branch, but how can I *easily” split
>> the checkin into two checkins, file A on one checkin and file B on the
>> other checkin?
> 
> In Fossil, committing creates a check-in which captures the entire state
> of the source tree at a moment in time.  This check-in is defined by a
> manifest artifact which in turn references file artifacts.
> 
> You seem to be asking how to edit that manifest artifact to reference an
> older version of one of the files, the one you didn't mean to check in
> at the same time as the other.
> 
> Fossil is specifically designed to prevent this sort of history
> tampering.  Instead, it provides the ability to push the unwanted
> manifest out of the way onto a branch (which can be hidden) then redo
> the commits as intended.
> 
> But all the above is me describing in greater detail an approach you
> already rejected.
> 
> So if you insist on something else, you might try experimenting with the
> "reparent" branch which provides a reparent command used to revise the
> predecessor version of a commit.
> 
> In the following, BADVER is the check-in version where you mistakenly
> committed changes to both A and B.  BASELINE is its predecessor.
> 
> 1. Build and install the "reparent" version of Fossil.
> 
> 2. Run "f up BASELINE" to go back before changes to A and B.
> 
> 3. Run "f revert -r BADVER A" to put in the change to A.
> 
> 4. Run "f commit -allow-fork -date-override DATE" where DATE is the
> version you intended to do the commit to A.  This will create a fork.
> 
> 5. Run "f reparent BADVER current" to make the current version be the
> predecessor of BADVER.
> 
> I don't like this approach.  It isn't how I'd go about things.  The
> reparent command is for fixing a damaged repository or for incorporating
> old history that wasn't available when the project was started.  But
> hey, it's an option.  Plus it would be nice for reparent to get some
> more testing.
> 
> When I try the above procedure, I wind up with two versions showing as
> leaf, just like when the fork occurred.  This is something that needs to
> be fixed in the reparent command.  Previously I found that this stays
> broken until a new branch is created.
> 
> -- 
> Andy Goth | 
> 
> ___
> 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] Automatic Ticket-commit tagging

[Steve Schow]

I’m sorry I’m not seeing anywhere that ticket “reports” are contained as 
versioned artifacts…


On May 22, 2016, at 2:50 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:

> On 5/22/2016 3:42 PM, Steve Schow wrote:
>> On May 22, 2016, at 1:40 PM, Ron W <ronw.m...@gmail.com> wrote:
>>> Everything in Fossil is stored in artifacts. 
>> 
>> Are ticket reports stored as versioned artifacts?
> 
> http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki#tktchng
> 

___
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] possible to change checkin?

[Steve Schow]

I’m still lost how I can split a checkin into two checkins.. 

let me try again…

Let’s say I have added file A…then never commit it…

a couple days later I add file B and hit commit

Suddenly I realize that two files were committed.  I want them both commited, 
but I want them committed as seperate checkins.

I can move the one checkin to a branch, but how can I *easily” split the 
checkin into two checkins, file A on one checkin and file B on the other 
checkin?
  




On May 22, 2016, at 2:46 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:

> On 5/22/2016 2:10 PM, Steve Schow wrote:
>> Is there currently any way in fossil to take a checkin and seperate
>> one of the files in the checkin to a seperate checkin?
>> 
>> Sometimes I occasionally hit commit and after committing realize there
>> was another unrelated file that I had added earlier for something
>> entirely different.  So two files end up commited with the checkin,
>> but really I would prefer if they had been seperate checkins.  Is
>> there currently any way to clean this up after the fact?  To move one
>> of the file changes to a different checkin?
> 
> You have two sensible options.  One, you could backout merge the
> check-in then follow it up with what you intended in the first place.
> Two, you could move the erroneous check-in to a branch, update to the
> prior check-in, then commit as intended.  I usually do the latter,
> naming the branch "mistake" and marking it as hidden and closed.
> 
> The third option is shunning.  Don't do that.  It's dangerous and far
> more trouble than it's worth.
> 
> -- 
> Andy Goth | 
> 
> ___
> 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] Automatic Ticket-commit tagging

[Steve Schow]

with regards to this statement…

On May 22, 2016, at 1:40 PM, Ron W  wrote:

> Everything in Fossil is stored in artifacts. 

Are ticket reports stored as versioned artifacts?


___
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] Automatic Ticket-commit tagging

[Steve Schow]

ok, but the ticket table does not contain artifacts.  It was not obvious to me 
that tickets are under version control in another place.  It is now.


On May 22, 2016, at 1:40 PM, Ron W <ronw.m...@gmail.com> wrote:

> On Sat, May 21, 2016 at 4:36 PM, Steve Schow <st...@bstage.com> wrote:
> Thanks for that information.  I was not aware that ticket changes involved 
> artifacts also.
> 
> Everything in Fossil is stored in artifacts. The DB serves as artifact 
> storage, indexing of artifacts and a convenient cache of data from the 
> artifacts. All the artifacts could be dumped into files, then later, a new DB 
> could be constructed from the artifacts.
>  
>   A few months back when I first started using fossil I batch changed a bunch 
> of tickets using SQL, I changed the value of the subsystem column..  since 
> then I’ve gone in and edited many of the same tickets using the web ui and 
> the subsystem value didn’t seem to revert back to anything, and everything 
> seems fine, but now you have me a little worried that in some cases the 
> artifacts of those tickets will be somehow out of sync with the SQL at some 
> point in the future.
> 
> As long as your repository is not exchanging ticket updates with another, the 
> DB tables should retain all the information.
>  
>  But thanks for the heads up, in the future if I am going to batch update a 
> bunch of tickets I will use the fossil ticket command to do it in some way.
> 
> That would be much safer.
> 
> ___
> 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] possible to change checkin?

[Steve Schow]

Is there currently any way in fossil to take a checkin and seperate one of the 
files in the checkin to a seperate checkin?

Sometimes I occasionally hit commit and after committing realize there was 
another unrelated file that I had added earlier for something entirely 
different.  So two files end up commited with the checkin, but really I would 
prefer if they had been seperate checkins.  Is there currently any way to clean 
this up after the fact?  To move one of the file changes to a different checkin?

___
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] Automatic Ticket-commit tagging

[Steve Schow]

Thanks for that information.  I was not aware that ticket changes involved 
artifacts also.  I should have known that, but I’m still getting up to speed 
with fossil.  A few months back when I first started using fossil I batch 
changed a bunch of tickets using SQL, I changed the value of the subsystem 
column..  since then I’ve gone in and edited many of the same tickets using the 
web ui and the subsystem value didn’t seem to revert back to anything, and 
everything seems fine, but now you have me a little worried that in some cases 
the artifacts of those tickets will be somehow out of sync with the SQL at some 
point in the future.

 But thanks for the heads up, in the future if I am going to batch update a 
bunch of tickets I will use the fossil ticket command to do it in some way.


On May 21, 2016, at 1:12 AM, Ron W <ronw.m...@gmail.com> wrote:

> On Fri, May 20, 2016 at 10:43 AM, Steve Schow <st...@bstage.com> wrote:
> I think perhaps you meant “commit” comment below?  Its the commit comment 
> that needs to be tweaked, in theory, by the TH1…not the ticket itself.   So 
> are you saying that modifying a commit comment requires that an artifact be 
> created with TH1 somehow, if even possible?
> 
> To truly update the commit comment, you need to create a control artifact 
> that "attaches" an updated comment to the commit. This involves two things: 
> Create a string with the required "cards" (see 
> http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki) then insert 
> the new artifact into the blob table. I don't know if the TH1 query function 
> will allow doing an insert or update. Have never tried.
>  
> For the ticket table, I noticed in the admin page that there is a SQL insert 
> statement with comments that say we can add our own columns to it for 
> whatever purpose we want.  It already has a status column which could be used 
> to store “working” status, but what I was thinking is I could stash something 
> in a different column that basically indicates its actually THE ONE that is 
> being worked on right now…  I don’t think (?) any artifacts are needed for 
> putting info like that into the ticket table and using TH1 to check out that 
> data from the ticket table…it would not be any new records, but rather an 
> additional column to an existing row in ticket table.
> 
> I think it would be ok to just update the one field in the ticket table. Just 
> be aware that a future update to the same ticket could cause fossil to 
> "forget" that change as there will be no artifact to "remind" it.
> 
> Alternately, both the web UI and the Fossil command line can update fields in 
> a ticket, so a ticket change artifact would automatically be created.
> 
> Which ever way the field gets set, a "SELECT tkt_uuid FROM ticket WHERE 
> working=yes;" should find and return the UUID of the currently "active" 
> ticket.
>  
> However, it makes sense that actually updating the commit comment would be 
> more involved, and plenty of opportunities to get it wrong if there is no API 
> for such a thing in TH1…sounds like  I would need have TH1 issue some SQL 
> that does it…and make sure the SQL is doing things right internally to create 
> this artifact you mentioned holding the updated commit comment.  Yes?
> 
> probabably easier and safer to just put this in the wrapper script I guess.
> 
> Yes. But it might actually be possible to do it with just TH1 hook scripts.
> 
> ___
> 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] Automatic Ticket-commit tagging

[Steve Schow]

I think perhaps you meant “commit” comment below?  Its the commit comment that 
needs to be tweaked, in theory, by the TH1…not the ticket itself.   So are you 
saying that modifying a commit comment requires that an artifact be created 
with TH1 somehow, if even possible?

For the ticket table, I noticed in the admin page that there is a SQL insert 
statement with comments that say we can add our own columns to it for whatever 
purpose we want.  It already has a status column which could be used to store 
“working” status, but what I was thinking is I could stash something in a 
different column that basically indicates its actually THE ONE that is being 
worked on right now…  I don’t think (?) any artifacts are needed for putting 
info like that into the ticket table and using TH1 to check out that data from 
the ticket table…it would not be any new records, but rather an additional 
column to an existing row in ticket table.  

However, it makes sense that actually updating the commit comment would be more 
involved, and plenty of opportunities to get it wrong if there is no API for 
such a thing in TH1…sounds like  I would need have TH1 issue some SQL that does 
it…and make sure the SQL is doing things right internally to create this 
artifact you mentioned holding the updated commit comment.  Yes?

probabably easier and safer to just put this in the wrapper script I guess.


On May 20, 2016, at 8:14 AM, Ron W <ronw.m...@gmail.com> wrote:

> On Fri, May 20, 2016 at 2:21 AM, Steve Schow <st...@bstage.com> wrote:
> Hmm, very interesting idea about using the EDITOR feature to run a 
> pre-script…i will have to ponder that…possibly an alternative to using an 
> actual wrapper script….
> 
> Sounds like server side TH1 probably won’t do it.
> 
> throwing a table into the checkout DB would be easy enough to do…can use 
> sqlite directly for that.  Its just a convenient place to put it.  I’d also 
> interact with the repo’s ticket table to look for tickets that are “working” 
> status, etc.  I was also thinking of adding a column to the ticket table in 
> the repo and then putting something there to indicate its the one I’m working 
> on…in which case I was thinking maybe TH1 could somehow pick it up…but it 
> sounds like the commit operation doesn’t get to the TH1 to do some action for 
> adding the ticket uid to its comment?
> 
> Fossil has "post commit" hooks for file commits and ticket updates that run 
> TH1 scripts configured by the Admin/Transfers page in the Fossil web UI.
> 
> While you might be able to change the various tables in the SQL database, 
> creating a "control artifact" to insert in the artifact table will also be 
> required. Other than the artifact table, the DB tables are caches of meta 
> data from the artifacts.
> 
> In theory, a field like "working on" could live only in the ticket table, but 
> could be cleared by other updates to the same ticket.
> 
> However, to insert the ticket ID into a ticket comment will require creating 
> a "control artifact" to contain the modified comment (see 
> http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki)
> 
> Alternately, you can edit the TH1 in the Edit Ticket UI page to support your 
> "working on this ticket right now" field. Then create a Ticket Report that 
> reports the currently "working on" tickets (if more than one ticket is 
> reported, you forgot to make the ticket as not "working on"). Then your 
> wrapper could use "fossil ticket show workReport" to get ID of "working on" 
> ticket and insert that ID in the commit comment.
> 
> ___
> 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] Automatic Ticket-commit tagging

[Steve Schow]

Hmm, very interesting idea about using the EDITOR feature to run a pre-script…i 
will have to ponder that…possibly an alternative to using an actual wrapper 
script….

Sounds like server side TH1 probably won’t do it.

throwing a table into the checkout DB would be easy enough to do…can use sqlite 
directly for that.  Its just a convenient place to put it.  I’d also interact 
with the repo’s ticket table to look for tickets that are “working” status, 
etc.  I was also thinking of adding a column to the ticket table in the repo 
and then putting something there to indicate its the one I’m working on…in 
which case I was thinking maybe TH1 could somehow pick it up…but it sounds like 
the commit operation doesn’t get to the TH1 to do some action for adding the 
ticket uid to its comment?


On May 19, 2016, at 11:24 PM, Ron W <ronw.m...@gmail.com> wrote:

> On Wed, May 18, 2016 at 2:12 PM, Steve Schow <st...@bstage.com> wrote:
> I’m going to try to make some kind of wrapper script to my commit command 
> that can do this for me, but before I embark I am wondering if anyone has 
> thought of any good ways to do this, perhaps using TH1 in the repo or 
> something….or perhaps using the checkout DB in some way to keep track of what 
> the current ticket is.
> 
> While TH1 has a query function to process SQL expressions in a TH1 script, 
> only the ticket hook script would be able to access the check out DB an donly 
> when triggered by a "fossil ticket" command line command. Even then, I don't 
> know if you'd have access to the check out DB.
> 
> A wrapper script might be able to use "fossil sql" command line commands to 
> store and retrieve info in the check out DB. I've never tried it.
> 
> The SQLite project has a command line client that could be used to store and 
> retrieve info in the check out DB.
> 
> My personal solution to this is to set the Fossil "editor" option to run a 
> script that launches my preferred text editor with the previous commit 
> message preloaded. Then I just edit what needs to be edited, save and quite 
> the editor. Then the script copies the message to the temporary file supplied 
> by 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] unable to move file

[Steve Schow]

yes I already understood that, I just couldn’t figure out why my fossil mv 
command wasn’t working

On May 19, 2016, at 3:55 PM, Warren Young <w...@etr-usa.com> wrote:

> On May 19, 2016, at 11:51 AM, Steve Schow <st...@bstage.com> wrote:
>> 
>> right, so how do i move a file in the repo from its existing location to a 
>> new subdir that doesn’t exist in the repo yet?
> 
> I see that you’ve fixed your immediate problem, but I still wanted to address 
> this question.  It’s based on a continuing misapprehension that you have to 
> tell Fossil about directories.
> 
> Try this:
> 
>  $ cd ~/some/fossil/checkout
>  $ mkdir foo
>  $ touch foo/bar
>  $ fossil add foo/bar
>  $ fossil ci
> 
> It will check in, and Fossil never had to be told about “foo” explicitly.
> 
> “foo” only exists within Fossil because “bar” exists.  If you remove “bar” 
> and check in again, Fossil won’t know anything about “foo”.
> ___
> 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] unable to move file

[Steve Schow]

I don’t know…it works now.. I don’t know what I was doing wrong before.  

Thanks!

On May 19, 2016, at 11:58 AM, dewey.hyl...@gmail.com wrote:

> what version of fossil are you using? 
> 
> this seems to work fine for me, even when only specifying a destination 
> directory without the filename:
> 
> [0] [dewey@macchiato:~] $ fossil version
> This is fossil version 1.34 [62dcb00e68] 2015-11-02 17:35:44 UTC
> 
> [0] [dewey@macchiato:~] $ mkdir -p footest/foo/some/new/directory
> 
> [0] [dewey@macchiato:~] $ fossil init footest/foo.fossil
> project-id: 0e8d0df2a808e05f5aaff16e8c16b2ed8715ce6f
> server-id:  26d036be1a4ccbeb29af8c71a27448ec8e7a77b7
> admin-user: dewey (initial password is "d62c07")
> 
> [0] [dewey@macchiato:~] $ cd footest/foo
> 
> [0] [dewey@macchiato:~/footest/foo] $ fossil open ../foo.fossil
> project-name: 
> repository:   /Users/dewey/footest/foo/../foo.fossil
> local-root:   /Users/dewey/footest/foo/
> config-db:/Users/dewey/.fossil
> project-code: 0e8d0df2a808e05f5aaff16e8c16b2ed8715ce6f
> checkout: 167ced8c5e85f6bfa703247bc96596f66021ed6c 2016-05-19 17:48:53 UTC
> tags: trunk
> comment:  initial empty check-in (user: dewey)
> check-ins:1
> 
> [0] [dewey@macchiato:~/footest/foo] $ echo here is a file > file.txt
> 
> [0] [dewey@macchiato:~/footest/foo] $ fossil add file.txt
> ADDED  file.txt
> 
> [0] [dewey@macchiato:~/footest/foo] $ fossil commit -m '+file.txt'
> New_Version: 348b7e01f88d636ad7c304d3d349d234ef6ad94c
> 
> [0] [dewey@macchiato:~/footest/foo] $ fossil mv file.txt 
> some/new/directory/file.txt
> RENAME file.txt some/new/directory/file.txt
> 
> [0] [dewey@macchiato:~/footest/foo] $ mv file.txt 
> some/new/directory/file.txt
> 
> [0] [dewey@macchiato:~/footest/foo] $ fossil commit -m 'mv file.txt'
> New_Version: 9050a79bffef0eb64d1d7d72de87fc2acfb745ce
> 
> [0] [dewey@macchiato:~/footest/foo] $ mkdir -p some/other/new/directory
> 
> [0] [dewey@macchiato:~/footest/foo] $ fossil mv 
> some/new/directory/file.txt some/other/new/directory/
> RENAME some/new/directory/file.txt some/other/new/directory/file.txt
> 
> - On May 19, 2016, at 12:45 PM, Steve Schow st...@bstage.com wrote:
> 
>> I am having a little problem with one thing in fossil, what am I doing wrong.
>> 
>> I have file:
>> 
>>/foo/bar/is/here
>> 
>> I want to relocate in the repository src try to:
>> 
>>   /foo/totally/new/location/here
>> 
>> /foo is the root of the checkout workspace.
>> 
>> the path /foo/totally/new/location/  doesn’t exist in the repo yet as there 
>> are
>> no other files checked in there.
>> 
>> When I try to use:
>> 
>>   fossil mv /foo/bar/is/here /foo/totally/new/location/here
>> 
>> I get an error:
>> 
>>  file outside of checkout tree: /foo/totally/new/location/here
>> 
>> 
>> I’m presuming this is because fossil only adds files, not dirs…and since 
>> there
>> are no files yet that deep, fossil doesnt know about the dir I want to put it
>> in.  I have already created the folder in the checkout workspace to move the
>> actual file to it…  And I did try to move the actual file there first
>> too…didn’t make any difference.
>> 
>> how do I do this?
>> 
>> 
>> 
>> ___
>> 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] unable to move file

[Steve Schow]

right, so how do i move a file in the repo from its existing location to a new 
subdir that doesn’t exist in the repo yet?

On May 19, 2016, at 11:47 AM, Richard Hipp <d...@sqlite.org> wrote:

> On 5/19/16, Steve Schow <st...@bstage.com> wrote:
>> I do not know how to checkin a dir to the repo without any files
> 
> You cannot.  Fossil only tracks files, not directories.
> 
> -- 
> 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] unable to move file

[Steve Schow]

As i said, the directory is already made.  but its not in the repo since there 
are no files in it yet checked into the repo.

I do not know how to checkin a dir to the repo without any files


On May 19, 2016, at 11:29 AM, Andy Goth <andrew.m.g...@gmail.com> wrote:

> What happens if you make the directory first?
> 
> On May 19, 2016 11:45, "Steve Schow" <st...@bstage.com> wrote:
> I am having a little problem with one thing in fossil, what am I doing wrong.
> 
> I have file:
> 
>  /foo/bar/is/here
> 
> I want to relocate in the repository src try to:
> 
> /foo/totally/new/location/here
> 
> /foo is the root of the checkout workspace.
> 
> the path /foo/totally/new/location/  doesn’t exist in the repo yet as there 
> are no other files checked in there.
> 
> When I try to use:
> 
> fossil mv /foo/bar/is/here /foo/totally/new/location/here
> 
> I get an error:
> 
>file outside of checkout tree: /foo/totally/new/location/here
> 
> 
> I’m presuming this is because fossil only adds files, not dirs…and since 
> there are no files yet that deep, fossil doesnt know about the dir I want to 
> put it in.  I have already created the folder in the checkout workspace to 
> move the actual file to it…  And I did try to move the actual file there 
> first too…didn’t make any difference.
> 
> how do I do this?
> 
> 
> 
> ___
> 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

[fossil-users] unable to move file

[Steve Schow]

I am having a little problem with one thing in fossil, what am I doing wrong.

I have file:

 /foo/bar/is/here

I want to relocate in the repository src try to:

/foo/totally/new/location/here

/foo is the root of the checkout workspace.

the path /foo/totally/new/location/  doesn’t exist in the repo yet as there are 
no other files checked in there.

When I try to use:

fossil mv /foo/bar/is/here /foo/totally/new/location/here

I get an error:

   file outside of checkout tree: /foo/totally/new/location/here


I’m presuming this is because fossil only adds files, not dirs…and since there 
are no files yet that deep, fossil doesnt know about the dir I want to put it 
in.  I have already created the folder in the checkout workspace to move the 
actual file to it…  And I did try to move the actual file there first 
too…didn’t make any difference.

how do I do this?



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

[fossil-users] Automatic Ticket-commit tagging

[Steve Schow]

I am getting tired of having to copy and paste the ticket uid into my commit 
comments in order to automatically link multiple commits to a single ticket.  
The ability to go to a ticket and see the list of checkins associate with it is 
very important to me, but the manual overhead to make it so, is cumbersome.  

I’m going to try to make some kind of wrapper script to my commit command that 
can do this for me, but before I embark I am wondering if anyone has thought of 
any good ways to do this, perhaps using TH1 in the repo or something….or 
perhaps using the checkout DB in some way to keep track of what the current 
ticket is.

Any creative ideas are welcome at this point…




___
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] Conversation with a CM guy

[Steve Schow]

me personally, if a potential employer wanted me to be a git guru, I wouldn’t 
take the job.  git gives me headaches beyond anything very simple, which as you 
said, can be learned in a day.

Git was one of the worst things to happen to the world of software engineering.

What makes git useful is the existence of github.  That’s about it.  Otherwise 
its a menace…


On May 16, 2016, at 12:44 PM, Eric Rubin-Smith  wrote:

>  employability. 
> 
> It takes less than a day to pick up git if you're used to fossil.  So I don't 
> really think it makes a huge difference as to future employability unless the 
> hiring manager is looking for the wrong things.
> 
> I grant that most hiring managers *do* look for the wrong things, but let's 
> not base decisions in our current project around the industry's silly hiring 
> practices.
> 

___
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] getting auto-sync error on server

[Steve Schow]

On May 3, 2016, at 12:33 PM, Richard Hipp  wrote:

> 
> WAL generally works better on servers.  You can see at
> https://www.fossil-scm.org/fossil/stat that my servers are generally
> in WAL mode.
> 

good to know.  I will change my server to WAL mode.  I presume I will need to 
change all repo files that my server is currently servicing.. I run the server 
daemon with a dir argument to pickup all the repos that are in that dir.  So I 
should make sure each of them is in WAL mode using the command you mentioned..  
cloned repos probably are fine without WAL mode I guess.
___
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] getting auto-sync error on server

[Steve Schow]

This is just a guess about the remote config…

First some background…

I have been unable to get the skins to change on my server repo when its 
running as 

   fossil server 

and connecting through the web to the named repo:

   http://host:port/repo/

I go to the admin-skins page, but click on the install button for all the 
different skins doesn’t change anything.

meanwhile, back on my cloned repo, I startup the gui using 

   fossil ui

and through that webpage, I can change the skins easily on the cloned repo.

At some point I think I probably tried to do a push config from the cloned repo 
back to the server repo, in hopes that I could push the skin there that way.  
Which didn’t work BTW.

Is it possible that when I did a push config, the remote config went with it, 
thus configuring the server to think it has a remote, which is itself?



On May 3, 2016, at 11:58 AM, Richard Hipp <d...@sqlite.org> wrote:

> On 5/3/16, Steve Schow <st...@bstage.com> wrote:
>> This particular repo is not a clone of another repo.
>> And it appears to be trying to sync with itself.
> 
> Huh.  I don't know how you got it into that state.
> 
> The solution is probably "fossil remote off".
> 
> 
> -- 
> 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] getting auto-sync error on server

[Steve Schow]

will try that.  thanks.  

about the other suggestion to WAL mode, do you generally think that is a better 
way to run sqlite whenever there is any chance of concurrency?  I was under the 
impression that it should work fine either way, but WAL just might provide some 
quicker response without having to wait on a locked DB file, but with other 
potential disadvantages which I can’t remember what they are right now..



On May 3, 2016, at 11:58 AM, Richard Hipp <d...@sqlite.org> wrote:

> On 5/3/16, Steve Schow <st...@bstage.com> wrote:
>> This particular repo is not a clone of another repo.
>> And it appears to be trying to sync with itself.
> 
> Huh.  I don't know how you got it into that state.
> 
> The solution is probably "fossil remote off".
> 
> 
> -- 
> 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] getting auto-sync error on server

[Steve Schow]

I will definitely try that, but the question I have is why is it trying to push 
or pull at all?  This particular repo is not a clone of another repo. And it 
appears to be trying to sync with itself.  Should I turn auto-sync off on a 
server that has no remote parent?  Its possible that sometime in the past I may 
have tried to push config from one of the clones to this one and perhaps that 
pushed information related to being a clone?  just wondering why its even 
trying to sync with itself at all…


On May 3, 2016, at 11:25 AM, Richard Hipp <d...@sqlite.org> wrote:

> On 5/3/16, Steve Schow <st...@bstage.com> wrote:
>> I am wondering what I have done wrong in my setup to get this error shown
>> below.  This is the first repo I created on a “server” box.  Its running in
>> server mode.  I cloned it on other machines, but I did not clone it on this
>> server machine.  Occasionally I get on the server box command line and add
>> some files directly to this server repo.   when I do, the commit seems to
>> attempt to do sync stuff with itself and generates these errors:
>> 
>> me@myhost:[/home/me/fossil]: fossil commit -m “this is how you do it"
>> Autosync:  http://me@myhost:8090/myrepo/
>> Round-trips: 1   Artifacts sent: 0  received: 0
>> Pull done, sent: 343  received: 2565  ip: 192.168.1.80
>> New_Version: f1867a08ba9d7117498e123d51e6c4dff5ce1755
>> Autosync:  http://me@myhost:8090/myrepo/
>> Round-trips: 1   Artifacts sent: 1  received: 0
>> Error: Database error: SQL error: database is locked
> 
> Perhaps on the server, run "fossil all rebuild --wal" to put all your
> repositories in WAL mode for better concurrency.  (This is a guess.)
> 
> 
>> Round-trips: 1   Artifacts sent: 1  received: 0
>> Sync done, sent: 2876  received: 277  ip: 192.168.1.80
>> Autosync failed.
>> 
>> Do I have something configured wrong or is it an error to try to run fossil
>> commands directly against a repo that is currently running in server mode?
>> 
>> 
>> ___
>> 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

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

[fossil-users] getting auto-sync error on server

[Steve Schow]

I am wondering what I have done wrong in my setup to get this error shown 
below.  This is the first repo I created on a “server” box.  Its running in 
server mode.  I cloned it on other machines, but I did not clone it on this 
server machine.  Occasionally I get on the server box command line and add some 
files directly to this server repo.   when I do, the commit seems to attempt to 
do sync stuff with itself and generates these errors:

me@myhost:[/home/me/fossil]: fossil commit -m “this is how you do it"
Autosync:  http://me@myhost:8090/myrepo/
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 343  received: 2565  ip: 192.168.1.80
New_Version: f1867a08ba9d7117498e123d51e6c4dff5ce1755
Autosync:  http://me@myhost:8090/myrepo/
Round-trips: 1   Artifacts sent: 1  received: 0
Error: Database error: SQL error: database is locked
Round-trips: 1   Artifacts sent: 1  received: 0
Sync done, sent: 2876  received: 277  ip: 192.168.1.80
Autosync failed.

Do I have something configured wrong or is it an error to try to run fossil 
commands directly against a repo that is currently running in server mode?


___
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 up repo to cloud service

[Steve Schow]

scratch that, I didn’t read you instructions carefully enough.  Not sure what 
the -R is…but it works if I copy and paste your line.

the resulting file, is that an actual atomically sound repo file, or some other 
kind of file that would need to be used for an import restore of some kind?


On May 2, 2016, at 6:17 PM, Richard Hipp <d...@sqlite.org> wrote:

> On 5/2/16, Steve Schow <st...@bstage.com> wrote:
>> On May 2, 2016, at 3:21 PM, Richard Hipp <d...@sqlite.org> wrote:
>> 
>>> If you want to make a guaranteed-consistent backup copy of a
>>> repository fail named "x.fossil" you can run the following command:
>>> 
>>>   fossil sql -R x.fossil ".backup x.bu"
>> 
>> 
>> When I try that I get -R unknown option.  ??
> 
> Really?  What does "fossil version" say?
> 
> -- 
> 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] backing up repo to cloud service

[Steve Schow]

On May 2, 2016, at 3:21 PM, Richard Hipp  wrote:

> If you want to make a guaranteed-consistent backup copy of a
> repository fail named "x.fossil" you can run the following command:
> 
>fossil sql -R x.fossil ".backup x.bu"


When I try that I get -R unknown option.  ??



> 
> I lease cheap server slices from Linode and Hurricane Electric (at
> geographically distributed data centers) and have clones of all my
> Fossil repositories on each.  They automatically sync with one another
> using a cron job.
> 
> Here at the office, we have many machines, which all serve as
> additional local backups by periodically running "fossil all pull".
> 

If that linode service provided more diskspace or a little cheaper I would 
definitely consider using it for my entire backup using rsync.  However for my 
purposes, I’m using Crashplan at $4/month for unlimited space..and I have about 
2TB of other stuff to backup, so I’d just prefer to get my fossil backed up 
there along with everything else.  I’m gonna ponder that linode service though, 
its interesting.  I might be able to use that in some way.  That would 
definitely be an excellent way to back up an SCM such as fossil!

Truthfully, I view the cloud backup as a last ditch backup in case the house 
burns down, as I have everything here backed up 1-3 times within the LAN.  
There are 4 computers with fossil and they are going to replicate the repos for 
sure, though I should make sure ALL repos are being replicated for that purpose.

I view that as the primary backup method.  Going to the cloud is really for 
worst case scenario…and if I have to restore from a SQL dump in that 
case…that’s fine….as long as its a complete backup.  


___
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 up repo to cloud service

[Steve Schow]

I wish to include my fossil repos in backup to cloud backup service.

what is the best approach for doing this?  if a fossil operation is in the 
middle of trying to do something when the automated cloud backup daemon decides 
to backup the repo file, I am presuming the backed up file could be in an 
inconsistent….non-atomic state.

Would it be preferable to do a sqlite dump or something of this nature and back 
that up to cloud service?




___
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] update vs checkout

[Steve Schow]

On Apr 30, 2016, at 11:27 PM, Scott Robison  wrote:

> 
> now you're ready to merge to trunk, so
> fossil update trunk
> MISSING STEP: fossil merge mybranch

yep I definitely missed that, thank you.


> (resolve merge conflicts and test merged workspace because it is possible 
> someone slipped another commit in after code review was passed)

true dat. 

Now I just need to make it easy to help them resolve merge conflicts…

Locating the common ancestor version of each file to use for the 3 way merge, I 
guess is the tricky part for that.

And I want to figure out a smart way to automate the copying and pasting of 
ticket uuid into all the commit comments.





___
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] update vs checkout

[Steve Schow]

> 
> On Apr 30, 2016, at 10:56 PM, Barry Arthur  wrote:
> 
>> The distributed/shared repository doesn't just hold trunk... it holds all 
>> non-private branches too. So when your developers are ready for you to 
>> review their work, they commit it to their task branch and then you 
>> (remotely) checkout/update to that branch (preferably into a fresh 
>> directory) and test/inspect their code. When you're happy with it, they (or 
>> you) can then merge their branch into trunk.
>> 


Sorry I didn’t read this carefully the first time.  Yes that is what i’m 
suggesting, I want to use the feature branch for both isolated development as 
well as code review prior to committing to the trunk.  Just trying to iron out 
exactly the sequencing of merge and update I need to do to create a smooth 
workflow for this.  I think I have it resolved now that I understand better the 
relationship and difference between update, merge and checkout…my original 
question.  

The work flow would be this:


(start with a clean checkout)
(work on code)
fossil commit —branch mybranch
fossil merge trunk
(resolve merge conflicts and test merged workspace)
fossil commit
(pass code review)
fossil update trunk
fossil commit

Here is a DOT diagram if you’re interesting.

digraph featurebranch {
rankdir="LR";
   node [shape=box];
   trunk->DeveloperA[color=red];
   DeveloperA->A2[weight=5,color=red];
   trunk->2[style=dotted,weight=8];
   A2->merge[weight=8,color=red];
   2->merge[style=dotted,color=red];
   merge->3[color=red];
   2->3[weight=8];

   trunk->developerB[style=dotted,color=blue];
   developerB->2[style=dotted,color=blue];
}





___
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] update vs checkout

[Steve Schow]

what you’re suggesting will not work unless I turn off auto-sync.  the authors 
of fossil have been very influential in convincing me to leave auto sync on.  
With auto sync on, then there is no way for me to remotely code review unless 
they commit to their repo, which would auto sync to the main repo.  So it has 
to be on a branch until it can be code reviewed.

I will be working with only a few contributors, most of whom have never used 
any version control ever.  I want it dummy proof.  In the rare instance when we 
may need to work around that paradigm I can get involved and help work with 
fossil commands directly.

Also I want to find a way to automate the copy and pasting of the ticket uuid 
into the commit comments.  So that will end up in the wrapper scripts also 
unless I can figure out a way to handle that through TH1.

If you have dot or graphviz, here is a small diagram showing what I think is 
probably the workflow.

digraph featurebranch {
rankdir="LR";
   node [shape=box];
   trunk->DeveloperA[color=red];
   DeveloperA->A2[weight=5,color=red];
   trunk->2[style=dotted,weight=8];
   A2->merge[weight=8,color=red];
   2->merge[style=dotted,color=red];
   merge->3[color=red];
   2->3[weight=8];

   trunk->developerB[style=dotted,color=blue];
   developerB->2[style=dotted,color=blue];

}



On Apr 30, 2016, at 10:56 PM, Barry Arthur  wrote:

> The distributed/shared repository doesn't just hold trunk... it holds all 
> non-private branches too. So when your developers are ready for you to review 
> their work, they commit it to their task branch and then you (remotely) 
> checkout/update to that branch (preferably into a fresh directory) and 
> test/inspect their code. When you're happy with it, they (or you) can then 
> merge their branch into trunk.
> 
> Private branches are not the default type of branch, so your devs would have 
> to go out of their way to get this wrong.
> 
> I wonder if your team has previously been using git...? I mean, is that the 
> reason why you want to create wrapper scripts instead of just letting your 
> devs learn to use the much simpler (compared to git) fossil commands 
> themselves?
> 
> Instead of wondering in thought space about how all these scenarios might 
> play out, you'd be much better off setting up a test repo and playing through 
> them until you and your team are comfortable with the tools and your workflow.
> 

___
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] update vs checkout

[Steve Schow]

On Apr 30, 2016, at 10:19 PM, Scott Robison  wrote:

> 
> So, update moves your working copy to the specified (or default) version 
> specified. Merge brings changes from the specified version into your working 
> copy without moving your working copy.
> 


I think this sounds like the key distinction..  

___
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] update vs checkout

[Steve Schow]

On Apr 30, 2016, at 6:55 PM, Richard Hipp  wrote:

> 
> Here you want "fossil update trunk" or "fossil checkout trunk" (They
> are the same thing here because you have not made any local changes
> since the last commit) followed by "fossil merge my branch”.


Yes I understand checkout will stomp over whatever is in my workspace rather 
then merging in the code.  Part of what I am wanting to do is prevent 
contributors from misusing commands at the wrong time.  I’m asking some of the 
questions just to have absolute clarity of what everything does.

By creating wrapper scripts that guide them through a process, this kind of 
accidental stomping over a workspace can be avoided.  I can step in for special 
circumstances to use direct fossil commands if and when its needed, which 
hopefully won’t be that often.  So for example, I see checkout as being 
relevant only at the start of a feature, with no current files added and 
waiting to be committed in the checkout.  But my understanding was that 
checkout will fail anyway if we have any uncommitted files, as long as we don’t 
try to force it with options.  

Update on the other hand will change which version the checkout is 
corresponding too, but with merged in stuff that i need to thnk about some more 
to make sure it will always be the behavior I want when switching between the 
base branch (i.e., normally the trunk, but not always), and the feature branch 
where isolated work is being done.



> 
> Think of "fossil update" (or "fossil checkout") as similar to the "cd"
> command in the shell.  It moves your working checkout to a different
> point on the graph.  The difference is that "fossil update" carries
> any local, uncommitted changes with you whereas "fossil checkout"
> abandons any uncommitted changes.  I never use "checkout" and suggest
> you do not either.  Forget it exists.  It is just confusing you.

I’m not confused about that.  Its the merging behavior I’m trying to get an 
absolute understanding of.  My only question about checkout at this point is 
whether it does an implicit pull.  My question about update and merge is about 
more specifically what is the difference between them and is there any way 
possible to merge two branches together in the repo?  I think no.




> 
> The "fossil merge" command then pulls the changes on some other point
> of the graph into your local workspace.
> 
>> 


Isn’t that what update does?



>> 
> 
> Here is one of countless actual examples of the above workflow:
> https://www.sqlite.org/src/timeline?b=4cbd5024=16=ci

Will definitely check this out in the morning.  Brain fried at the 
moment…thanks though, you always seem to dig great examples out of your sqllite 
history!

The main thing I’m trying to figure out, as mentioned in the other email to 
Scott, is..how to be able to isolate developer activity to a branch which can 
be code reviewed remotely, ideally with a review of exactly what it is they are 
going to commit to trunk shortly….ie…the final merged code, just prior to being 
committed to the trunk.  

If I am understanding correctly, all merging in fossil happens into the checked 
out workspace.  you can merge in from any other version in the repo, and it 
will attempt to retain the changes you’ve made in your workspace while merging 
them with whatever other version of of the repo you specify.  In the case of 
the update command it also changes the checkout’s notion of which checkin it 
corresponds to.But how to get this merged together code into the repo prior 
to committing to the trunk, is the part I’m not sure how to do exactly the 
right way.  It sounds like what actually needs to happen is, just prior to code 
review:

while the checkout points to the leaf of mybranch, merge the leaf of trunk into 
mybranch and keep the checkout corresponding to the leaf of mybranch.  

so in the above sentence, after I have some commit —mybranch, and a few more 
commits…the checkout is corresponding to the leaf of mybranch.  I want to stay 
on mybranch while merging in the leaf of trunk.  So should I use "fossil merge 
trunk", to bring all the latest trunk change into mybranch in the workspace?  
followed by a commit to push all that merged stuff into to mybranch in the repo 
where it can be code reviewed?  Once its code reviewed there, then finally do 
fossil update trunk, to bring it back to the trunk of my workspace, and finally 
commit again to finally commit all of the merged changes to the trunk?

So i get the following workflow

fossil open or checkout to leaf of trunk (assuming no uncommitted changes yet)
work on code
fossil commit —branch mybranch  (commits new changes on a 
branch in the repo
fossil merge trunk   (brings the 
workspace up to date with everything that has happened on trunk and branch)
(test again)   
fossil commit   (commits the 
merged changes 

Re: [fossil-users] update vs checkout

[Steve Schow]

On Apr 30, 2016, at 6:55 PM, Richard Hipp <d...@sqlite.org> wrote:

> On 4/30/16, Steve Schow <st...@bstage.com> wrote:
>> 
>> So in some ways this seems that when update is called in this “non-standard”
>> way, its a bit more like a “merge”.
> 
> (1) This way isn't "non-standard".  It is the usual use-case for "update”.


wait now I’m confused.  I assumed the “standard” way is fossil update without 
any version specified, which looks for the newest leaf from where we currently 
are checked out from.  By non-standard, and I didn’t mean anything judgmental 
by that, I just meant trying to run update with a VERSION that isn’t even on 
the same branch…but  I must not be understanding the command still….since it 
sounds like you are saying its the normal desirable thing to specify some other 
ancestor VERSION or version from another branch?…I hope you’re saying that this 
is in order to merge another branch into this one…within the repo.  Yes?

its not clear to me how I can create a merged branch somewhere that has all of 
the tentative changes….in the repo…that can be reviewed remotely….before 
commiting to the trunk.  Sounds to me like its not possible currently with 
fossil.

What exactly is the difference between merge and update? 

___
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] update vs checkout

[Steve Schow]

On Apr 30, 2016, at 6:55 PM, Scott Robison  wrote:

> 
> No. If you are on mybranch and you have uncommitted changes, and you run 
> update trunk, your changes will not be committed to mybranch (effectively 
> they will be reverted) and then they will be automatically applied to your 
> working copy of trunk you just updated to.


So both merge and update merge into the checked out workspace, they do not 
merge into a branch in the repo under any circumstances?

___
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] update vs checkout

[Steve Schow]

Merge conflicts are possible ANY time someone else edits a file and commits it 
to the trunk while you have been working on a feature branch rather then the 
trunk for a while.  Lots of times, the software can merge without conflicts, 
but sometimes no.  And me personally I actually prefer to visually inspect all 
merges, and manually approve them, but that’s just me and my OCD.

My workflow list may not be correct as I sit here thinking about it….and one 
thing may have just become clear to me, please correct me if I’m wrong:

merge merges a version into the checkout DB, without effecting the repo.

update merges changes into a branch within the repo (and also the checkout db).

yes?

My two major goals here are this:

1 - I want devs to be able to work on a feature and commit their changes to 
their repo without hitting the trunk right away.  thus the feature branch.  no 
problem there.

2 - I want to code review exactly what they are going to commit to the trunk 
right before they do it.  The problem I see is that “merge" merges into their 
checkout, not their repo, so there is no way to remotely code review the final 
thing they are about to commit to the repo trunk.  what needs to happen is that 
I need to have the trunk merged into their feature branch so that the final 
merged result will already be in the repo to be reviewed remotely.

So as I think about it…I don’t want to use merge..  perhaps this is a matter of 
using the leaf of trunk to merge into their feature branch…if that’s even 
possible.  Then their feature branch will be the whole merged enchilada that 
can be code reviewed remotely.  Once approved, they have to quickly use merge 
to merge the branch into their workspace, do a quick test and then finally 
commit to repo trunk.

so

> fossil checkout trunk
> (work on code)
> fossil commit —branch mybranch
> (work on more code)
> fossil commit
> fossil update -n (i want to have the branch look like the trunk leaf is 
> merged into it, if that’s possible)
> (resolve merge conflicts when they rarely occur ;-)
> fossil update
(code review my branch)
   switch context back to trunk for their checkout, not sure exact command to 
use yet)
  fossil merge mybranch
> (final feature test)
> fossil commit


___
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] update vs checkout

[Steve Schow]

On Apr 30, 2016, at 5:01 AM, Richard Hipp  wrote:
> 
> Your current check-out and VERSION will have a common ancestor X.
> Fossil finds all the differences between X and the current check-out,
> then applies those differences to VERSION.


So in some ways this seems that when update is called in this “non-standard” 
way, its a bit more like a “merge”.  In my mind, “update” brings the checked 
out workspace up to date with the rest of the repo if anyone has added stuff on 
the same branch its on.  Its like a specific use case of merge, with an 
implicit pull added in.  yes?  what else would distinguish update from merge 
when its called that way?

Normally update is doing a merge where the common ancestor is the checked-out 
version itself, and it merges in the leaf from there, as long as there isn’t 
already more then one leaf.  That’s more likely to be an easy merge, and also 
the sensible one.  That’s the normal default behavior without a VERSION 
argument.  I guess what you’re saying is that in all other cases where its not 
a descendant, then fossil does the “merge” behavior of looking for the the 
nearest common ancestor and then merging from there, more like what the “merge” 
command does, but with an implicit pull also.   Do I have that right? 

I’d post a dot graph here, but I’m not sure if the mail list allows us to 
attach images or not?

Just trying to make sure I understand all of the commands before before I write 
some wrapper scripts, but the workflow I am hoping to promote here is this:

fossil checkout trunk
(work on code)
fossil commit —branch mybranch
(work on more code)
fossil commit
(code review)
fossil update trunk -n
(resolve merge conflicts when they rarely occur ;-)
fossil update trunk
(final feature test)
fossil commit


> 
> Fossil runs the 3-way merge automatically.  That is what "fossil
> update" does.  There is no extra work to do on your part.

I’m presuming what you mean is that during update, fossil attempts to 
automatically do a 3 way merge..and when there is a conflict it just bombs out 
and you can then undo it if you want.  I already presumed that to be the case, 
and I presume that update -n would tell us info about the merge conflict?  If 
not, then this is all a moot point I guess.

What I wish to do is catch that situation proactively and automatically guide 
the user through the process of resolving the conflict by automatically 
providing the common ancestor and two versions to compare and if possible go 
ahead and feed that to a graphical diff tool that supports 3 way merge.  Then 
they can merge it and save the result in their checkout workspace.  Then a 
subsequent call to update should not fail from merge conflict.  If update -n 
does not provide the information needed to do the 3 way manual merge, such as 
common ancestor and the two versions being compared…then this is a moot point 
unless there is some other way I would be able to script that information based 
on update -n or something?


>> 
> I so rarely use "checkout" that I don't remember :-)  Use the source, Luke!
> 
> — 


Can you elaborate a bit on what you mean here by use the source luke?





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

[fossil-users] update vs checkout

[Steve Schow]

More Noob questions.

Trying to understand the subtle difference between the checkout command and 
update.  is it fair to say that checkout will stomp over the top of the current 
working checkout area with the repo version you checkout from, while the update 
command will merge the changes into the working checkout merging the actual 
code in and retaining the work in progress?  Do I have that right?

what happens if an update VERSION is specified that is not a descendant of the 
node we checked out from?  What if the VERSION is on a completely different 
branch?

In both merging and updating, there is a possibility for merge conflicts.  
update -n will let us check to see if there are some but what is the automated 
way to resolve merge conflicts during or just prior to a merge?  The 3 way 
merge command is probably the way to do it I guess, so I am assuming the answer 
to my question is in order to bring a working checkout up to date with the 
branch its on, first run update -n, if there are noted merge conflicts, then 
use the information to run the 3 way merge tool to update the working checkout 
in such a way that running update -n no longer produces a merge conflict, then 
finally run update to bring the working checkout completely up to date with the 
branch it its on, and work in progress still retained.  Do I have that right?  
Any suggestions about automating that process?

fossil update does an implicit pull before bringing the repo up to date before 
bringing the working checkout up to the leaf of the branch its on, presuming 
you don’t try some funny business with the VERSION argument, does fossil 
checkout also do an implicit pull?

thanks






___
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] Ticket Report questions

[Steve Schow]

On Apr 26, 2016, at 2:02 PM, Steve Schow <st...@bstage.com> wrote:

Regarding this question:


> 1 - Looks like there is TH1 script to determine what values can be chosen 
> from the ticketing webgui for filling certain fields, like status, priority, 
> severity, etc.  I want to sort my ticket reports based on severity, priority. 
>  I can see how to update the SQL in the report definition to have the fields 
> I want, ordered and colored however I want.  Great.  However, it looks to me 
> like a collating sequence is really needed to make ordering make sense…  
> "Important" needs to be at the top of the list, not “cosmetic”, for example.  
> Ideally the list would sort based on the same collating order that is shown 
> in the actual TH1 script used to fill the GUI top to bottom.  But somehow I 
> don’t think that is possible without a collating sequence so that the SQL 
> command of the ticket report will be able to do what it needs to do.  It 
> seems to me that I would need to manually add a collating sequence to sqlite 
> and then use it in the report.  The bummer is that I am guessing this object 
> would not get cloned or sync’d to other repos, but please correct me if I’m 
> wrong.  Or maybe there is a better way to handle this task to get the ticket 
> list sorted in an order that makes sense to me..not alphabetical.  I can of 
> course put numbers into the values for severity and priority, which would 
> then sort things appropriately, but with ugly numbers showing up all over the 
> place, including in the ticket reports.

I figured out a solution directly in the SQL select statement without any 
collating sequences or anything FWIW.  If there is a simpler solution please 
let me know but this seems to do the trick.


ORDER BY 
  CASE severity
WHEN 'Critical'   THEN 0
WHEN 'Severe'THEN 1
WHEN 'Important'   THEN 2
WHEN 'Minor' THEN 3
WHEN 'Cosmetic'THEN 4
WHEN 'Dreamer' THEN 5
   ELSE 6
  END,
  CASE priority
WHEN 'Immediate'  THEN 0
WHEN 'VeryHigh'THEN 1
WHEN 'High'   THEN 2
WHEN 'Medium'  THEN 3
WHEN 'Low'THEN 4
WHEN 'VeryLow' THEN 5
WHEN 'Zero'   THEN 6
  ELSE 7
  END

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

[fossil-users] Ticket Report questions

[Steve Schow]

Some more Noob questions

Just trying to fine tune the ticketing system for my own needs.

1 - Looks like there is TH1 script to determine what values can be chosen from 
the ticketing webgui for filling certain fields, like status, priority, 
severity, etc.  I want to sort my ticket reports based on severity, priority.  
I can see how to update the SQL in the report definition to have the fields I 
want, ordered and colored however I want.  Great.  However, it looks to me like 
a collating sequence is really needed to make ordering make sense…  "Important" 
needs to be at the top of the list, not “cosmetic”, for example.  Ideally the 
list would sort based on the same collating order that is shown in the actual 
TH1 script used to fill the GUI top to bottom.  But somehow I don’t think that 
is possible without a collating sequence so that the SQL command of the ticket 
report will be able to do what it needs to do.  It seems to me that I would 
need to manually add a collating sequence to sqlite and then use it in the 
report.  The bummer is that I am guessing this object would not get cloned or 
sync’d to other repos, but please correct me if I’m wrong.  Or maybe there is a 
better way to handle this task to get the ticket list sorted in an order that 
makes sense to me..not alphabetical.  I can of course put numbers into the 
values for severity and priority, which would then sort things appropriately, 
but with ugly numbers showing up all over the place, including in the ticket 
reports.

2 - When I changed the SQL for a ticketing report, even just slightly like 
remove a field, the report now has a big blank white space in between each row. 
 Is this a bug or something I’m doing wrong?  Possibly this is related to the 
AS ‘_comments’ part of the SQL..that is perhaps different then the actual 
default report is, I’m not sure.  Just trying to understand.  No actual 
comments are showing up in the report in that white space…so maybe that is what 
is confusing me, I notice when I don’t have any _ then no white space.  
Comments?

3 - I notice when I hover the mouse over the header row of the ticket list, it 
changes to a finger cursor..implying that there may be some functionality for 
clicking on the header of the column, but nothing seems to happen.  Any comment 
about that?

4 - this is actually more related to the timeline, but my timeline always shows 
‘Ticket’.title, on the timeline for each ticket…rather then the actual text of 
the title, it shows this SQL syntax instead.  I tried to adjust the definition 
under timeline settings, to Ticket.title, which just shows that..  is something 
broken in Fossil or am I doing something wrong?  How can I get the actual 
ticket title and/or comments into the timeline?

5 - After having created a hundred tickets or so, I realized that I would like 
to have a certain tag in the sub-system field.  I see that I need to go add 
them with TH1, fine.  however, what is the ok way to go back to add those tags 
to all my hundred tickets.  Will it be ok to use a SQL statement to manually 
set the value of that field enmass to a bunch of tickets, or will that in any 
way confuse some fossil artifact somewhere?  Is ticket data stored anywhere 
besides in the ticket table which would get confused if I manually change those 
values directly with SQL?  same goes if I want to go tweak a bunch of the title 
fields where i actually put my own all caps word in each title for the 
sub-system (before I realized there was a dedicated field for it, since its not 
on the NEW ticket page (yet).

6 - I notice that when I create a new ticket, the combo box for priority shows 
the first item on the list.  If I don’t change it…then null is stored in the DB 
rather then that value.  Seems like these combo boxes should default to what is 
going to be stored..if NULL is the default, then show blank unless I manually 
select a value.  Or is there a way to configure things so that they will be 
defaulted to a particular value rather then displaying something the user may 
assume is going to be stored, but isn’t going to be stored unless they change 
the combo box explicity.  Am I making sense?

enough for now...


___
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] Can't change skins on server repo

[Steve Schow]

haven’t used that command yet at all.  i wasn’t trying to copy skins from local 
to server, I was just trying to login to the webui on the server and use it 
directly through the webui.  Go into admin section and hit the link for skins 
and then there are install buttons for each of the skins you guys have 
provided, but they don’t change anything, the skin always just stays on the 
default one.

I only mentioned the local repo because when I use the webui of the local repo 
I am able to change the skins just fine.  When I try to use the webui of the 
non local repo…I can’t change the skins.


On Apr 25, 2016, at 11:46 AM, Richard Hipp <d...@sqlite.org> wrote:

> On 4/25/16, Steve Schow <st...@bstage.com> wrote:
>> I’m having trouble changing skins.  It works on my local repo, but not on
>> the server repo.
>> 
>> 1 - created repo on machine A.  setup user foobar with s privs.
>> 
>> 2 - created clone of that repo on machine B.  also with user foobar with s
>> privs
>> 
>> 3 - Working on the local machine B, I can run fossil ui, and i’m able to
>> change the skins all i want.
>> 
>> 4 - if I start machine A as a server with “fossil server’ and then connect
>> to that ui from machine B…I’m able to create tickets and everything else
>> I’ve tried has worked but if I try to chose a different skin, it just stays
>> on the default.
>> 
>> what am I missing?
> 
> Did you do "fossil config push skin" to move your local changes over
> to the server?
> 
> -- 
> 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] Can't change skins on server repo

[Steve Schow]

I’m having trouble changing skins.  It works on my local repo, but not on the 
server repo.

1 - created repo on machine A.  setup user foobar with s privs.

2 - created clone of that repo on machine B.  also with user foobar with s 
privs 

3 - Working on the local machine B, I can run fossil ui, and i’m able to change 
the skins all i want.

4 - if I start machine A as a server with “fossil server’ and then connect to 
that ui from machine B…I’m able to create tickets and everything else I’ve 
tried has worked but if I try to chose a different skin, it just stays on the 
default.  

what am I missing?

___
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] Colored output on console

[Steve Schow]

I’m new to fossil and thanks for pointing out this  wrapper tool I’m going to 
check it out for sure!


On Apr 25, 2016, at 8:48 AM, Michael Richter <ttmrich...@gmail.com> wrote:

> I know that every time I mention this I get silently, perhaps even hostilely, 
> ignored, but really guys, why not just use fsl for your customization needs?  
> Colourizing output is in the cookbook: 
> http://fossil.0branch.com/fsl/wiki?name=Cookbook, along with lots of other 
> nifty tricks like aliasing, adding commands (like workflow-based ones I've 
> done for my stuff), etc.  It really is a nifty little package and I don't get 
> the hostility (or at least utter apathy) it generates in the Fossil community.
> 
> I look forward to the "ignore the very existence of this message" that is 
> traditional each time I bring it up.
> 
> On 25 April 2016 at 09:48, Steve Schow <st...@bstage.com> wrote:
> For now, if you’re on a unix platform, you can try a wrapper script like this:
> 
> 
> 
> #!/bin/bash
> 
> export COLOR_NC='^[[0m'
> export COLOR_RED='^[[1;31m’
> 
> fossil $* |\
> sed -e "s/ERROR/${COLOR_RED}ERROR${COLOR_NC}/g” \
> sed -e “s/WARNING/${COLOR_RED}WARNING${COLOR_NC}/g”
> 
> 
> 
> 
> 
> 
> 
> On Apr 24, 2016, at 4:07 AM, Marko Käning <sec001+fos...@posteo.net> wrote:
> 
> > Hi devs,
> >
> > it would be great if one could colorise Fossil’s output on the console!
> >
> > Quite a few times I missed an error or warning message which slipped in 
> > between of many lines of the usual fossil output on the console.
> >
> > Red colouring of words like “warning” or “error” would be very helpful 
> > there.
> >
> > The poor man’s solution would at least be to use capital letters and some 
> > sort of line head along the lines of
> >
> >   > ERROR: blaa
> >   > WARNING: blubb
> >
> > Right now I can’t send an example of such a easily slipping through 
> > message, but I can deliver if I come across one again.
> >
> > Greets,
> > Marko
> >
> > ___
> > 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
> 
> 
> 
> -- 
> "Perhaps people don't believe this, but throughout all of the discussions of 
> entering China our focus has really been what's best for the Chinese people. 
> It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
> ___
> 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] Colored output on console

[Steve Schow]

On Apr 25, 2016, at 9:22 AM, Stephan Beal  wrote:

> 
> 
> On Mon, Apr 25, 2016 at 4:48 PM, Michael Richter  wrote:
> http://fossil.0branch.com/fsl/wiki?name=Cookbook, 


> fwiw, i think you've misconstrued the conventional silence. i've always 
> intended it as, "whew! We dodged that bullet again!"
> 


Stephan…I’m new here.  What do you mean by “dodged a bullet?  Is fsl something 
to be afraid of for any reason?  I don’t want to waste my time if so.  but I 
know I am going to  write my own wrapper scripts.  So I’m genuinely interesting 
in anything that anyone else has done.

I just perused it a little bit and at least my first impression is that it may 
be over engineered a bit, with a lot of TCL flexibility, but therein lies the 
potential source of user error bugs in the creation of custom TCL scripts to 
make it do what you want it to do…so…  is that what you mean by dodged a bullet?


___
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] Colored output on console

[Steve Schow]

For now, if you’re on a unix platform, you can try a wrapper script like this:



#!/bin/bash

export COLOR_NC='^[[0m'
export COLOR_RED='^[[1;31m’

fossil $* |\
sed -e "s/ERROR/${COLOR_RED}ERROR${COLOR_NC}/g” \
sed -e “s/WARNING/${COLOR_RED}WARNING${COLOR_NC}/g”







On Apr 24, 2016, at 4:07 AM, Marko Käning  wrote:

> Hi devs,
> 
> it would be great if one could colorise Fossil’s output on the console!
> 
> Quite a few times I missed an error or warning message which slipped in 
> between of many lines of the usual fossil output on the console.
> 
> Red colouring of words like “warning” or “error” would be very helpful there.
> 
> The poor man’s solution would at least be to use capital letters and some 
> sort of line head along the lines of
> 
>   > ERROR: blaa
>   > WARNING: blubb
> 
> Right now I can’t send an example of such a easily slipping through message, 
> but I can deliver if I come across one again.
> 
> Greets,
> Marko
> 
> ___
> 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] Some more default settings for a UI user

[Steve Schow]

On Apr 23, 2016, at 4:19 PM, Marko Käning  wrote:

> Hi,
> 
> it would be nice to have some default settings definable for a user:
> 
> • Timeline view:
> - Type of entries (e.g. only check-ins)
> - Max. 
> - With/Without Files
> 
> • Files view:
> - would be nice to be able to set it e.g. by default to tree-view.


+1
___
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] Code blocks with more vertical space possible?

[Steve Schow]

I’m just getting up to speed with fossil myself, but my impression is that you 
will get the most mileage if you use raw HTML to format your wiki pages rather 
than mark down or the fossilwiki format, whatever that is.  I have also gotten 
some strange results using the WYSIWYG editor.  Myself I am probably going to 
start doing my wiki pages outside of the web editor altogether using a 3rd 
party HTML editor…and then save the files through normal version control and 
there is a way with fossil to have references to those through the wiki 
site..this is  nice because then the docs also sit in the normal src tree for 
reference there.


On Apr 23, 2016, at 4:06 PM, Marko Käning  wrote:

> Hi,
> 
> is it possible to define code-blocks which
> 
>  1) have extra vertical space for better separation
> in paragraphs or stg like list items?
> 
>  2) have perhaps even a frame around them?
> 
> 
> I guess this all could be achieved by some CSS magic,
> but I think it would be nice to have that as standard
> behaviour. 
> 
> E.g. in "Review Board"’s or GitHub’s wiki syntax one
> can use three apostrophes
> ```
> to mark a code block (like this)
> ```
> which will then be rendered with more vertical space
> and in case of RB also with a box around it.
> 
> 
> Perhaps this is also possible in Fossil’s wiki, but
> my tries to get something similar using Fossil’s
> Markdown syntax weren’t successful up to now.

___
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] Version control as backup. Was: Noob usage questions

[Steve Schow]

it sounds to me like your repos are backed up well as long as they are all 
completely sync’d with each other on a regular basis and so long as they are 
located on different HDD volumes and at least one copy offsite from one of the 
other copies.  Your versioning history is very well backed up for sure due to 
the distribution.

However

Its not clear from your description whether the workspaces of your devs are 
backed up.

Also your backup may or may not cover certain odd cases.  For example, what if 
some piece of data inside the Sqlite db file is changed, something that is not 
under version control per say, its just some SQL data being used..config data 
or whatever…  And then 3 days later you realize someone changed that data…  if 
that data was sync’d between all repos during those 3 days, then the original 
is gone now, no way to get it back unless you have an actual backup of your DB 
file that was done totally outside of Fossil’s internal versioning and syncing 
capabilities.

In practical terms, you’re covered very well I’d say.



On Apr 23, 2016, at 12:15 PM, Richard Hipp <d...@sqlite.org> wrote:

> On 4/23/16, Steve Schow <st...@bstage.com> wrote:
>> 
>> version control is definitely not a backup ...
>> 
> 
> Why not?  What am I missing?
> 
> For Fossil and for SQLite, our "backup" is 3 copies of the
> repositories for each project, running in three different datacenters,
> using two separate providers, plus all the local copies we have of
> each repo.  The main repositories stay synced with each other
> automatically (using cron jobs on the servers).  On my (numerous)
> development machines, I frequently do "fossil all sync" which
> synchronizes all my private copies of the various repos as well.
> 
> So there are many copies of each project, each copy including all
> history going back many years, stored at multiple sites around the
> world, and constantly updated.
> 
> How can a backup strategy improve on that?
> 
> -- 
> 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] Noob usage questions

[Steve Schow]

On Apr 23, 2016, at 12:14 AM, Scott Robison <sc...@casaderobison.com> wrote:

> On Sat, Apr 23, 2016 at 12:06 AM, Steve Schow <st...@bstage.com> wrote:
> 
> does that change the workspace implicitly to be checked out to that branch 
> instead of the trunk?  Does the workspace then become tied implicitly to the 
> branch unless specifically checked out back to the trunk or another branch?
> 
> Yes.
>  


Thanks for confirming that



___
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] Noob usage questions

[Steve Schow]

On Apr 23, 2016, at 12:33 AM, Ron W  wrote:

> 
> Also, for us, almost all tickets are entered through the web interface. 
> Although Fossil's hooks feature works with tickets as well as with commits, 
> there is no mechanism to create a new branch from a hook script.
> 


I still have to grok all the TH1 script stuff to see what is possible with it.  
I was under the impression it is mostly useful for  creating more dynamic web 
content, but if its possible to hook into commit actions and block them or 
ensure [nn] ticket numbers get added to commit comments, or when 
branches are created add tags automatically, etc…then I will definitely have a 
look at that.   Anything that I can hide inside the server rather then depend 
on client side wrapper scripts would be preferable.

> 
> Before Fossil, we were using a commercially available VCS that did force 
> doing development on branches, then merging to trunk, so we were already used 
> to doing that.
> 
> Our work rules require that each of us take time each day to review pending 
> code changes. Most days, our integration person will have a few changes to 
> integrate, so not much time is required. If a problem comes up in 
> integration, that merge will be discarded and the issue related to the change 
> that failed integration will be marked "InDev". The person who worked on that 
> change set will then be responsible for fixing the problem in consultation 
> with the authors of the "conflicting" changes.


+1


> As I said in my previous message, users' local repos can use either 
> "autosync=pullonly" or "don't-push", which will impede pushing changes to the 
> upstream (or main) repo - or any other repo. But, as I said, users can change 
> those settings. You would have to trust them to not do so with out a very 
> compelling reason.


Yea, for various different reasons I think I would prefer if their changes go 
to the server on their own branch.  But I will think about that pull only 
option to see if may make any sense here.


> Alternately,Fossil does have provisions for "hooks". Currently, the hook 
> scripts have to be written in TH1 (which can have TCL expressions embedded in 
> it.) I have never done this, so I don't know how it works.


I’d like to find some more out about TH1.  I was under the impression from 
everything I read so far, that its mostly useful for creating dynamic web 
content, It was not obvious to me as of yet how it could be used to “hook” into 
commit events, or branch events, etc…and update the data in the process.  The 
evil thought also crossed my mind of adding some SQL triggers to sqlite which 
check for undesirable commits or pushes and basically force an error which 
would theoretically rollback the transaction and prevent it from happening, 
albeit with an entirely un-useful error message.  I know…evil… 
___
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] Noob usage questions

[Steve Schow]

On Apr 23, 2016, at 12:44 AM, Ron W  wrote:

> 
> Another potential problem with private branches: Because they don't get 
> pushed, you loose the safety net of having them replicated in another 
> (preferably remote) repo.


Not only the safety net, but also the easy ability for everyone to see what 
everyone else is working on at any time.  The whole point of the private branch 
is that nobody else can even see it.  


> 
> Remember: Version control is not - in and of itself - a backup. You need to 
> properly backup your repo. You should also properly backup workspace (and PC).
> 
> 


Definitely not.  Version control is about tracking changes and in our cases, 
associating all code changes to tickets, etc.  We need to not only restore a 
file, or a file from a few days ago…but often need to actually go back years in 
time, see exactly what someone did in some code, think about that and how it 
impacts our software, and continue working on it.  

All my local machines except for one linux server are macs backed up by time 
machine.  So I can even go back a few months to restore a lost file.  But 
restoring a lost file is not what version control is about, its about actually 
looking at the differences between versions and getting into WHAT changed 
between versions, WHO did it and WHY.   And the reason for a central SCM server 
is more about code sharing between the devs.  In my case, there are folks 
outside of my local network who may participate in development and I can’t 
guarantee they will have any backup of their local PC happening at all, so I’d 
rather have them pushing their commits as often as possible to my backed-up SCM 
server.

version control is definitely not a backup though, its a working area where 
development work takes place.  the SCM itself needs to be backed up somewhere 
else, and don’t forget to the cloud if possible.


___
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] Noob usage questions

[Steve Schow]

On Apr 22, 2016, at 11:34 PM, Ron W  wrote:

> My team's wrapper for Fossil does the following (from memory, so might not be 
> exactly right):
> 
> On "branch new":
>fossil commit --allow-empty --branch $bname -m "$comment (Issue [$issue])"
>fossil tag add --propagate issue $bname $issue 
> 
> On "commit":
>$issue=`fossil tag ls $revision|perl -n -e 'if /issue=(\w+)/ { print $1; }`
>fossil commit -m "$comment (Issue [$issue])" $args


I have been perusing all the docs all evening, I can’t actually see any way to 
tell fossil which branch to commit to, so there must be some implicit behavior 
here that I am overlooking.  I can see that “checkout” is the command that 
checks out a workspace to a given VERSION, which exists on either the trunk or 
some branch.  

When you do the 

commit —branch

does that change the workspace implicitly to be checked out to that branch 
instead of the trunk?  Does the workspace then become tied implicitly to the 
branch unless specifically checked out back to the trunk or another branch?

and thus a subsequent commit would be to the end of that branch rather then the 
trunk?  Am I right to conclude that at this point if the dev issues a checkout 
command again against a VERSION on the trunk, then subsequent commits would go 
to the end of the trunk rather then the branch?

Do I have that about right?

if so, not a big deal then, just have to use wrapper scripts to make sure to 
follow your work flow, always create a new branch on the first commit for any 
ticket.  I will probably use a cookie or something to make sure while working 
on a ticket, all commits go to that branch, and tag the commit with the 
[nn] number as well.

 If they need to work on more than one ticket concurrently, then no big deal, 
create another branch and switch to that one for a while.

if they need to do something directly to the trunk, then checkout trunk and 
just do it without code review, which is sometimes the case for some sys admin 
stuff.

I’m starting to get my head around fossil I think..












___
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] Noob usage questions

[Steve Schow]

On Apr 22, 2016, at 10:35 PM, Ron W  wrote:
> 
> At work, my team keeps autosync on. We do all our code changes in branches. 
> Our workflow is:
> 1. An issue ticket is created, describing either a problem or a specification.
> 2. (wait until issue is reviewed and approved)
> 3. A branch is created for that issue.
> 4. Make code changes, perform tests, committing as appropriate. (see note #1)
> 5. When done and all tests passed, change issue state to "In_Review".
> 6. Review proposed code.
> a. If rejected, revert issue to either "InDev" or "OnHold". Go back to #4
> b. If approved, set issue to "Integrating"
> 7. Merge final commit of issue branch to trunk and test.
> a. If tests pass, set issue to "Integrated"
> b. If tests fail, set issue to "InDev". Go back to #4
> 8. When a "validation release" is made, set integrated issues to 
> "InValidation".
> 

Nice work flow…

In the above workflow, here are my questions:

1 - step#4 is fine because dev is working on a branch.  do you have any 
mechanisms in place to prevent them from accidentally committing a file on the 
trunk instead of the branch at this stage of the workflow?

2 - step #8 should have the final commit I guess, because #7 merge only merges 
into the checkout workspace to do final integration test.


Overall I like this workflow, but I would like to make sure they can’t 
accidentally push stuff from one repo to the other that they may have committed 
to their own own repo, perhaps from a different workspace or by accident to the 
trunk instead of the feature branch.  Since push and pull always transfer the 
entire repo with all versions that are there…if they updated their local repo’s 
trunk in any way whatsoever, perhaps totally unrelated to the ticket…it could 
slip through the cracks and be pushed to the central server repo without any 
code review or notice.

What am I missing?  How can that situation be caught or prevented?




___
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] Noob usage questions

[Steve Schow]

Beautiful explanation!  Thank you!  The dot clicking functionality is really 
very cool, that actually makes everything way easy to deal with, as far as code 
review…especially with the background color stuff in there.  The Webgui is 
starting to make more sense to me as I look at these examples.

I am definitely of the opinion also that in situations like that the feature 
branch should DEFINITELY not squash the commits and throw them away…so I’m with 
you guys on that one!  I guess its just a matter of making it easy for the code 
reviewer to review the change prior to the merge.  But the color coding and 
graph tree you guys have put on this web page make that very easy enough!  And 
actually pretty easy to make a lot of various different diffs quickly and 
easily to grok the change before allowing the merge.

One question about the example you gave me…  Did joe explicitly create a branch 
called “warnings” to do his fix and merge it back to the main trunk or is that 
implicitly showing his work on his own repo?  I’m assuming the first 
explanation to be the case but please correct me if I’m wrong.

I’m presuming that by having a different branch, he can call commit numerous 
times.. (which implicitly calls pull before and push after right?), but since 
he has his own feature branch its no problem, its just pushing that branch to 
the server repo ( as long as he doesn’t have any other forgotten about changes 
on his local main trunk).   That is probably the general work flow method i 
would like to standardize on.  

brings me to another question though…is there any way for me to block people 
from being able to push their local trunk to the another repo trunk?  In 
essence forcing them to use Joe’s approach.  Looks like push is always for the 
whole repo, so when they call push or commit, then the whole repo is going to 
get pushed to the server repo…including perhaps things they forgot they were 
working directly on the main trunk in their local repo.  wrapper scripts can 
hopefully guide them towards always working on a branch, but I have to think 
that through.

Another question, what exactly is the different between pull and update?




On Apr 22, 2016, at 7:31 PM, Richard Hipp <d...@sqlite.org> wrote:

> On 4/22/16, Steve Schow <st...@bstage.com> wrote:
>> 
>> Im not sure if you’re saying a merge here would
>> merge multiple commits from one branch into a single commit on the dest
>> branch?  You said it preserves the history, but that would infer that the
>> merge would not squash the commits in the process.
>> 
> 
> Here is an simple example:
> 
>   https://www.sqlite.org/src/timeline?c=2016-04-13
> 
> Ignore the tempfiles-25 and tempfiles-lazy-open branches - those are
> concurrent activities that do not play into this discussion.  I'm
> looking at the "warning" branch with three check-ins by Joe (userid:
> mistachkin) starting on 2016-04-12 20:05.
> 
> Joe did three check-ins to fix compiler warnings.  [ab69527c],
> [7faec9ea], and [929fa4c3].  He then asked me (userid: drh) to look
> them over and merge them if he thought they were appropriate, which I
> did at [68142dc5].  Do you see the branch I'm talking about?
> 
> Notice that after Joe made his changes, but before they were merged, I
> checked in another unrelated change directly to trunk at [83cfe82c].
> 
> You can see a "squash" of Joe's three commits in several ways:
> 
> (1) Click on the circular graph node for the baseline of Joe's
> changes, which is [bedb88a4].  You'll notice that the center of the
> circle turns red.  Then click on the circle for the last of Joe's
> check-ins [929fa4c3].  You will then see a diff which is the aggregate
> of Joe's three check-ins.  It is showing you an aggregate diff from
> the baseline (the circle with the red dot in the middle) to the second
> node you clicked on, which is same thing as the "squashed" check-in.
> 
> Hint:  Click on the circle with the red dot again to turn the red dot off.
> 
> (2) Click on the "[68142dc5]" hyperlink to the merge check-in and look
> at its diff.  That check-in merged all changes in the "warnings"
> branch into trunk, so it should show mostly the same diff as (1).
> (Any variance is because (1) is using [bedb88a4] as its baseline where
> as (2) is using [83cfe82c].  In this case, as in the vast majority of
> cases, the changes from [bedb88] to [83cfe8] are be well separated
> from the changes in the "warnings" branch and hence the diffs will be
> identical.)
> 
> (3) You can also do this from the command-line by typing:  "fossil
> diff --from bedb88 --to 929fa4 --tk" or something similar.
> 
> -- 
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users maili

Re: [fossil-users] Noob usage questions

[Steve Schow]

On Apr 22, 2016, at 5:07 PM, Richard Hipp  wrote:

> If you want see a sequence of changes as a single diff, bring up a
> timeline that shows all the changes, click on the "node" of the
> origin, then click on the last check-in, then it will show you a diff
> between those two nodes.

this works good, that feature was not completely obvious, but is very helpful. 
thanks.


___
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] Noob usage questions

[Steve Schow]

On Apr 22, 2016, at 5:07 PM, Richard Hipp <d...@sqlite.org> wrote:

> On 4/22/16, Steve Schow <st...@bstage.com> wrote:
>> 
>> 1 - I notice tickets numbers are not automatically cross linked with
>> commits.
> 
> Links are automatic if you include the ticket number [nn]
> somewhere in the check-in
> comment.  See the check-in at
> https://www.sqlite.org/src/timeline?c=ab9d279f40f81e5a for a recent
> example.  Notice how that check-in includes the ticket number in the
> check-in comment, and the ticket number gets crossed out automatically
> when the ticket is closed.
> 
> If you click on the link to the ticket number, it takes you straight
> to the ticket.  Then on the ticket page, you can click on "Timeline"
> in the submenu bar to see
> https://www.sqlite.org/src/tkttimeline/7d7525cb01b68 all check-ins
> associated with that ticket.
> 
> I suppose the ticket timeline could be cleaned up a little to give it
> all the same features as the regular timeline.  I just seldom use the
> ticket timeline so it hasn't gotten as much attention.  (An
> opportunity for you to contribute!)
> 


Right well I’m just trying to figure out a way to automate thing so the dev 
never has to worry about copy and pasting any kind of ticket or checkin numbers 
from one place to another.  I want it to just happen automatically through 
wrapper scripts and workflow control.  

This is also a bit confusing to me about the implication of many commits 
corresponding to a single ticket.  I will play around with it some more until I 
grok it a little more.  Perhaps I just need to learn which is the right web 
screen to look at… 

Ideally, as a gatekeeper, having to look through a list of commits when 
reviewing the changes for a ticket…its difficult.  What’s better is to see a 
list of files being effected in the ticket (across all the commits it has) and 
the macro diff for each of those files..for the whole ticket..not just one 
commit at a time.   So that is easy in the git world if the dev is told to 
squash their commits before a pull request.  In Fossil we can’t squash, but we 
need to make it easy for the gatekeeper to see a squashed view of the requested 
changes for the ticket across multiple commits.  Also in the future it would be 
good to tag the final commit of the ticket…so that anyone trying to look at 
stuff later will be able to see the interim commits are half-fixes for the 
ticket.  The full ticket is only represented by the range of version 
nodes..with the last one being the one that matters the most..  


> 
> The equivalent to squashing commits is to do the work on a branch,
> then merge the branch when it is done.  The merge take the place of
> the squash, but preserves the history.
> 


In the past on other systems I’ve used like clear case, we always did work on 
another branch and the merge did squash the commits arriving on the dest branch 
in the process.  Im not sure if you’re saying a merge here would merge multiple 
commits from one branch into a single commit on the dest branch?  You said it 
preserves the history, but that would infer that the merge would not squash the 
commits in the process.  



> If you want see a sequence of changes as a single diff, bring up a
> timeline that shows all the changes, click on the "node" of the
> origin, then click on the last check-in, then it will show you a diff
> between those two nodes.
> 


Ah…I will try this out..  I didn’t know you could click between two nodes and 
see the diff.  I will try that…that might provide enough.  Even more ideally 
I’d like to write a wrapper script that will figure out the diff and present 
diff or gdiff to the gatekeeper.  Gatekeeper would see a list of files changing 
between the two more extreme nodes of the ticket…show the list of files and one 
at a time the diff.  I guess this is doable with scripting...



>> 
>> 3 - whether to use auto-sync or not.  I would like to enforce a work flow
>> where devs are not able to move any changes back to the mainline until it
>> passes code review.
> 
> The Fossil idea is that it provides mechanism, not policy.  Policy
> issues such as "do not merge to trunk until approved" are enforced
> administratively.  If is an accidental commit to trunk occurs, that
> commit can be moved back out into another branch when the mistake is
> discovered.  If other commits have occurred on top of it, use the
> --backout option to back out the changes with yet another commit.
> 
> https://www.sqlite.org/src/timeline?c=f632bba0 is an example of doing
> a commit incorrectly, then moving it off into a separate branch after
> the mistake is discovered.  I originally (mistakenly) did the check-in
> on trunk.  Then as a separate step I moved it into a branch, continued
> working on the feat

[fossil-users] Noob usage questions

[Steve Schow]

I have just discovered fossil and I am kind of blown away by all it can do!  I 
love how simple this is to install and administrate for small projects.  The 
other competing products like GitLab or Phabricator, etc, are orders of 
magnitude too complicated for small projects that just need some src control, 
wiki docs, issue tracking and maybe a bit of branch-management workflow 
adherence.  Huge SQLite fan here, I’m definitely going to give this a go!

I have read the ebook and perused through the email archives a bit, I have a 
few questions before i go much further.

1 - I notice tickets numbers are not automatically cross linked with commits.  
The book mentions adding the [n] strings in both directions so that at 
least through the webui you can at least  hyper link back and forth..presuming 
there is only one commit for a given ticket.  if there is more then one commit, 
it could get complicated.  This definitely needs to be automated with wrapper 
scripts to avoid user error.Do any of you have any wrapper script examples 
or work flow suggestions to make this a little more automatic and reliable?  

Basically I would like a workflow where developer Joe gets a ticket.  He works 
on the ticket for a while, doing whatever commits he feels he needs to do, and 
finally when its done, closes the ticket with references to the commit(s) in 
the ticket.  But in the future I want to easily be able to call up a ticket, 
via the web or not, and see a list of files that were changed and diffs of what 
was actually changed related to that ticket…ideally consolidating all the 
commits into one reviewable diff for the whole ticket, if that makes sense.  
Any workflow or scripting suggestions will be appreciated.  Has anyone 
considered modifying the actual ticket tables to hold references to commit(s) 
directly rather then as text strings in the description?  Something that can’t 
be easily changed through user error?  What is the best way people are 
automating or streamlining this capability to make it more automatic, 
consistent and enforced?

2 - I notice fossil doesn’t endorse or seem to directly support the squashing 
of commits.  In git I can work on a bunch of stuff, commit it 10 times or 
whatever, and then before doing a pull request to push it back to the server 
repo, I can consolidate those commits to a single commit so that what ends up 
on the server repo will be one single commit  as a single ‘feature” or “idea”.  
That one single commit can then be referenced by a ticket if it exists (see 
question #1).   Is there a way to squash commits with fossil or perhaps other 
workflows with branches or tags that can enforce this kind of end result where 
the server mainline trunk will have a single commit per ticket, regardless of 
whatever mess of multiple commits the developer did in their local repo?  Or at 
least a way for a ticket to easily see the files changed and the diff of those 
changes for the ticket as a whole…even if that is over multiple commits?  
Prefer to see multi-commits squashed to single commits during push or merge to 
the server mainline.

3 - whether to use auto-sync or not.  I would like to enforce a work flow where 
devs are not able to move any changes back to the mainline until it passes code 
review.  they need to be able to pull from the trunk (or not) as they work to 
keep their workspace up to date (or not) and work on their feature, whether its 
a big feature or a single line bug fix, but not able to push it back to 
mainline until I say so via gatekeeper code review, and confirmation that they 
have updated their workspace with all the latest changes from mainline and 
built with it before being able to merge back to mainline also.

So being able to both enforce this and also facilitate easy code review of the 
requested change…is what I would like to automate with wrapper scripts for 
fossil.  It needs to be consistent and easy and very straightforward for code 
reviewing as well, if there are 10 commits they did, the code reviewer 
shouldn’t have to worry about any of that.  Just take a ticket id, see a list 
of files changed and the overall diff of each file that is expected to be 
merged back to mainline in some fashion, and associate it all with a ticket id, 
and approve the ticket and the dev can finally commit it back.

In the past on other systems I have used “feature-branches” where developers 
create a feature branch for each change or at least reuse a private branch they 
have..and then after they do all the work they are going to do, finally request 
code review and maybe their commit(s) will be merged back to the mainline.   
Nobody works off the mainline, they always work off a branch and after code 
review can merge their branch back to the mainline…or rather merge the specific 
commits from their branch, into the mainline…  I don’t know if this is making 
sense, but any insights, wrapper script ideas or other ideas about how to setup 
fossil in