Re: [fossil-users] Two easy questions

[Roy Keene]

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


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


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


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

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

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


Thanks,
Roy Keene

On Wed, 16 Aug 2017, Stephan Beal wrote:


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


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


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

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

Options:

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



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

--
- stephan beal
http://wanderinghorse.net/home/stephan/"Freedom is sloppy. But since tyranny's 
the only guaranteed byproduct of those who insist on a perfect world,
freedom will have to do." -- Bigby Wolf

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

Re: [fossil-users] Two easy questions

[Johan Kuuse]

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

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

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

BR,
Johan

>
> [stephan@host:~]$ f help whatis
> Usage: f whatis NAME
>
> Resolve the symbol NAME into its canonical artifact hash
> artifact name and provide a description of what role that artifact
> plays.
>
> Options:
>
>--type TYPE  Only find artifacts of TYPE (one of: 'ci', 't',
> 'w', 'g', or 'e').
>-v|--verbose Provide extra information (such as the RID)
>
>
>
> But, correct: if someone edits the file (i.e. changes the hash) then this is
> useless.
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
> those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two easy questions

[Stephan Beal]

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

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

Naw - there've been a few longer ones.


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

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

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

Options:

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



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

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two easy questions

[David Mason]

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

> shasum urltags.js
1bea11bf4a97b012e7d8b17c71a7d444f0b5a5aa
> fossil ui

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

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

Re: [fossil-users] Two easy questions

[Andy Bradford]

Thus said Steve Schow on Tue, 15 Aug 2017 15:50:39 -0600:

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

Whatever you end up doing, if possible please report back to the mailing
list for the sake of the archive.  That way if someone has the same need
that you did, they might find your solution feasible for them.

Thanks,

Andy
--
TAI64 timestamp: 40005993ad5a
___
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  wrote:
> 
> On Aug 15, 2017, at 3:58 PM, Steve Schow  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

Re: [fossil-users] Two easy questions

[Warren Young]

On Aug 15, 2017, at 3:58 PM, Steve Schow  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

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  wrote:
> 
> On Aug 15, 2017, at 3:50 PM, Steve Schow  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  wrote:
> 
> On Aug 15, 2017, at 3:50 PM, Steve Schow  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

Re: [fossil-users] Two easy questions

[Warren Young]

On Aug 15, 2017, at 3:50 PM, Steve Schow  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

Re: [fossil-users] Two easy questions

[Warren Young]

On Aug 15, 2017, at 3:50 PM, Steve Schow  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

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  wrote:
> 
> On Aug 15, 2017, at 3:07 PM, Steve Schow  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

[Warren Young]

On Aug 15, 2017, at 3:07 PM, Steve Schow  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.




ship
Description: Binary data
___
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  wrote:
> 
> On Aug 15, 2017, at 2:53 PM, Steve Schow  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

[Warren Young]

On Aug 15, 2017, at 2:53 PM, Steve Schow  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

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  wrote:
> 
> On Aug 15, 2017, at 12:09 PM, Steve Schow  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

[Warren Young]

On Aug 15, 2017, at 11:41 AM, Steve Schow  wrote:
> 
> 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?

What does “fossil set autosync” say?
___
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

[Warren Young]

On Aug 15, 2017, at 11:58 AM, Richard Hipp  wrote:
> 
> With git and hg, your repository and
> checkout are more closely bound and are strictly one-to-one.

Not “strictly.”

Git has the git-worktree command as of 2.5 which links the current checkout to 
a new working directory:

https://git-scm.com/docs/git-worktree

Unfortunately, it’s got a number of problems, most stemming from the fact that 
the feature was grafted onto Git something like a decade after the repository 
format was designed:

0. It’s still considered an “experimental” feature, according to the docs.

1. Programs that expect to find a .git subdirectory with known contents get 
confused because .git is now a file that points to the other repository.

2. You can’t have the same branch in two worktrees on the same machine for some 
reason.

3. It doesn’t work with submodules.

4. Because it does its job by linking one tree to another using paths on disk, 
the links are easily broken with an mv or rm command, which then means you 
can’t check in changes from any of the worktrees.

Fossil checkouts are independent of each other.  Though they are dependent on 
the path to the .fossil file, I more rarely feel a need to move my ~/museum 
directory around than I feel a need to move checkout directories around.  The 
latter is safe with Fossil, but not with Git worktrees.

5. It’s a relatively new feature, being added to Git only about 2 years ago, so 
it’s not yet available in “stable” OSes like RHEL 7, Solaris 11, etc.  Thus, 
you can’t always count on having it everywhere you work.
___
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

[Warren Young]

On Aug 15, 2017, at 12:09 PM, Steve Schow  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

Re: [fossil-users] Two easy questions

[Stephan Beal]

On Tue, Aug 15, 2017 at 9:50 PM, Steve Schow  wrote:

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

That's... not wrong. Close enough :). You do have to commit after adding
it, though, or it will not be added. The "add" command actually just queues
it up for adding at the next commit (which can be performed together with
any number of other changes). From that point on, fossil tracks any changes
you make to it.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two easy questions

[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  wrote:
> 
> On Tue, 15 Aug 2017 19:57:34 +0200, Steve Schow  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  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

[j. van den hoff]

On Tue, 15 Aug 2017 19:57:34 +0200, Steve Schow  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   
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

[Stephan Beal]

On Tue, Aug 15, 2017 at 9:24 PM, bch  wrote:

> I'm not following the process. Fossil guarantees hash fidelity - explain
> differently how this would work and be coherent w/i fossil?
>

i'm not discounting that it could work exactly as you describe, but i would
consider it a "highly unfortunate" feature to add to fossil (or any SCM,
for that matter). It adds the complexity of a 2nd hash for the 1-in-100k
case of "needing" to perform text replacement at checkin-time. Any such
system is inherently not "commit what you test" because what you committed
cannot possibly be what you tested, as the contents have necessarily
changed between testing and committing.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two easy questions

[bch]

On Aug 15, 2017 11:49, "Stephan Beal"  wrote:

On Tue, Aug 15, 2017 at 8:47 PM, Joerg Sonnenberger  wrote:

> On Tue, Aug 15, 2017 at 08:18:08PM +0200, Stephan Beal wrote:
> > 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).
>
> It can be done, just replace the keyword expansion with a canonical form
> whenever hashing the content. Keeping the original hash and the hash of
> the expanded form allows faster working copy modification checks.
>

You're to blame when that feature request arrives ;).


I'm not following the process. Fossil guarantees hash fidelity - explain
differently how this would work and be coherent w/i fossil?

-bch



-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf

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

Re: [fossil-users] Two easy questions

[Stephan Beal]

On Tue, Aug 15, 2017 at 9:10 PM, Stephan Beal  wrote:

> A user can ALWAYS check contents in to a fossil repo
>

Filesystem permissions permitting, of course. You can't commit changes to a
repo opened from a CD or other read-only media.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two easy questions

[Stephan Beal]

On Tue, Aug 15, 2017 at 8:55 PM, Steve Schow  wrote:

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

Then i misunderstood your use of "add", as it seems to match how git works.


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

Unlike RCS, fossil (or any DVCS) does not record in the central repository
that you have checked it out. There is no server-side record that you have
done so. Fossil is, AFAIK, unique in that a single clone of a repository
can be checked out any number of times. The connection between your machine
and the server(s) is managed solely in terms of a repo db (a "clone" is a
copy of such a repo db, created via the "clone" command). A checkout is
simply one instance of "opening" a clone to gain access to its contents.
Fossil neither needs to know, nor cares, whether a given checkout will be
used for reading or writing. A user can ALWAYS check contents in to a
fossil repo, but they MIGHT not be able to push any changes to a remote
copy (depends on their permissions).


> In fossil we use “add” which includes the file to a set of files that will
> be commited in the next commit.
>

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

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  wrote:
> 
> On Tue, Aug 15, 2017 at 8:43 PM, Steve Schow  > 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/ 
> 
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of 
> those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

Re: [fossil-users] Two easy questions

[Stephan Beal]

On Tue, Aug 15, 2017 at 8:47 PM, Joerg Sonnenberger  wrote:

> On Tue, Aug 15, 2017 at 08:18:08PM +0200, Stephan Beal wrote:
> > 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).
>
> It can be done, just replace the keyword expansion with a canonical form
> whenever hashing the content. Keeping the original hash and the hash of
> the expanded form allows faster working copy modification checks.
>

You're to blame when that feature request arrives ;).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two easy questions

[Stephan Beal]

On Tue, Aug 15, 2017 at 8:43 PM, Steve Schow  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/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two easy questions

[Joerg Sonnenberger]

On Tue, Aug 15, 2017 at 08:18:08PM +0200, Stephan Beal wrote:
> On Tue, Aug 15, 2017 at 8:09 PM, Steve Schow  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).

It can be done, just replace the keyword expansion with a canonical form
whenever hashing the content. Keeping the original hash and the hash of
the expanded form allows faster working copy modification checks.

Joerg
___
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  wrote:
> 
> 
> 
> On Tue, Aug 15, 2017 at 8:09 PM, Steve Schow  > 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/ 
> 
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of 
> those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

Re: [fossil-users] Two easy questions

[Stephan Beal]

On Tue, Aug 15, 2017 at 7:54 PM, Steve Schow  wrote:

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

Fossil has never been known to lose data. AFAIK it's the only SCM which can
make that claim. Even a rebuild fails horribly halfway through, the whole
thing is happening via an SQL transaction, so no data is lost (barring
horrible hardware corruption).


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

As Richard described: sync synchronizes the remote and local databases,
which (yes) includes the wiki and tickets. It doesn't update your local
files, though. (Because of that, sync can be performed without a checkout.)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two easy questions

[Stephan Beal]

On Tue, Aug 15, 2017 at 8:09 PM, Steve Schow  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/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two easy questions

[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  wrote:
> 
> On 8/15/17, Steve Schow  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

[Richard Hipp]

On 8/15/17, Steve Schow  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

Re: [fossil-users] Two easy questions

[Richard Hipp]

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

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

[Stephan Beal]

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

Re: [fossil-users] Two easy questions

[Stephan Beal]

Sync doesn't modify the checkout. Use update for that.

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

On Aug 15, 2017 19:47, "Steve Schow"  wrote:

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

Re: [fossil-users] Two easy questions

[Stephan Beal]

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