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
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
>>
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
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
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
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
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
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:
>>
>>
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
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
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
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,
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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",
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
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
> >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
>
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
45 matches
Mail list logo