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 ha
dia.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
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 r
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
> wrote:
>
> Thus said Steve Schow on Fri, 29 Sep 2017 15:43:38 -0600:
>
&g
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 wrote:
>
>> On 9/29/2017 4:43 PM, Steve Schow wrote:
>>> On Sep 29, 2017, at 2:46 PM, Andy Goth wrote:
>
> 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
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 cou
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
diagram on my wiki page
without that HTML option checked?
> On Aug 15, 2017, at 5:34 PM, Steve Schow wrote:
>
> hmm, I created a new repository and works fine there…very strange..
>
>
>> On Aug 15, 2017, at 5:09 PM, Warren Young wrote:
>>
>> On Aug
hmm, I created a new repository and works fine there…very strange..
> On Aug 15, 2017, at 5:09 PM, Warren Young wrote:
>
> On Aug 15, 2017, at 4:46 PM, Steve Schow wrote:
>>
>> i’m getting the same result with new tickets, or adding on to tickets, makes
>> no
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 wrote:
>
> On Aug 15, 2017, at 4:23 PM, Steve Schow wrote:
>>
>> I have tried with a blank line between the paragraph an
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 wrote:
>
> On Aug 15, 2017, at 4:12 PM, Steve Schow wrote:
>>
>> yes
t; On Aug 15, 2017, at 3:55 PM, Steve Schow 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
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 d
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 com
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
, 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
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 com
017, 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.
, 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 deploym
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:
&
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
>>
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
017, at 12:48 PM, Stephan Beal wrote:
>
> On Tue, Aug 15, 2017 at 8:43 PM, Steve Schow <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
Tue, Aug 15, 2017 at 8:09 PM, Steve Schow <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
> featur
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 t
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 p
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
s,
> and top-posting.
>
> On Aug 15, 2017 19:48, "Steve Schow" <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 > <mailto:sgb...@go
n 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&quo
.
> 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 in
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 ma
May 23, 2016, at 2:14 AM, Ron W wrote:
> On Sun, May 22, 2016 at 4:42 PM, Steve Schow wrote:
>
> 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
22, 2016, at 6:52 PM, Andy Goth 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.
, 2016, at 6:43 PM, Andy Goth 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
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 wrote:
> On 5/22/2016 3:42 PM, Steve Schow wrote:
>> On May 22, 2016, at 1:40 PM, Ron W wrote:
>>> Everything in Fossil is stored in arti
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 wrote:
> On 5/22/2016 2:10 PM, Steve Schow wrote:
>> Is there currentl
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
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 wrote:
> On Sat, May 21, 2016 at 4:36 PM, Steve Schow wrote:
> Thanks for that information. I was not
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 e
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 wrote:
> On Fri, May 20, 2016 at 10:43 AM, Steve Schow wr
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 wrote:
> On Fri, May 20, 2016 at 2:21 AM, Steve Sc
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 wrote:
> On Wed, May 18, 2016 at 2:12 PM, Steve Schow wr
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 wrote:
> On May 19, 2016, at 11:51 AM, Steve Schow wrote:
>>
>> right, so how do i move a file in the repo from its existing locati
t/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 S
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 wrote:
> On 5/19/16, Steve Schow wrote:
>> I do not know how to checkin a dir to the repo without any files
>
> On May 19, 2016 11:45, "Steve Schow" 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/locat
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 i
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,
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 t
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 fi
Hipp wrote:
> On 5/3/16, Steve Schow 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 of
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 wrote:
> On 5/3/16, Steve Schow wrote:
>> This particular repo is not a clone of another repo.
>> And it appears
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 wrote:
> On 5/3/16, Steve Schow 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
May 2, 2016, at 6:17 PM, Richard Hipp wrote:
> On 5/2/16, Steve Schow wrote:
>> 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
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 s
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 a
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 an
>
> 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) c
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
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 distinc
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 o
On Apr 30, 2016, at 6:55 PM, Richard Hipp wrote:
> On 4/30/16, Steve Schow 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
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 co
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 visua
I forgot one step in this process I want:
On Apr 30, 2016, at 5:56 PM, Steve Schow wrote:
>
>
> fossil checkout trunk
> (work on code)
> fossil commit —branch mybranch
> (work on more code)
> fossil commit
> (code review)
> fossil update trunk -n
> (resolve me
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 t
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 th
On Apr 26, 2016, at 2:02 PM, Steve Schow 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
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 Apr 25, 2016, at 11:46 AM, Richard Hipp wrote:
> On 4/25/16, Steve Schow 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.
>>
>
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,
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 Sc
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
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,
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
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
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 wrote:
> On 4/23/16, Steve Schow wrote:
>>
>> version control is definite
On Apr 23, 2016, at 12:14 AM, Scott Robison wrote:
> On Sat, Apr 23, 2016 at 12:06 AM, Steve Schow 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
>
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
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 w
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 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 create
through.
Another question, what exactly is the different between pull and update?
On Apr 22, 2016, at 7:31 PM, Richard Hipp wrote:
> On 4/22/16, Steve Schow wrote:
>>
>> Im not sure if you’re saying a merge here would
>> merge multiple commits from one branch into a sing
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 g
On Apr 22, 2016, at 5:07 PM, Richard Hipp wrote:
> On 4/22/16, Steve Schow 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-i
erent branch). then the code review process can happen
completely in the server repo and using a merge to bring the changes back into
mainline there.
On Apr 22, 2016, at 5:31 PM, Thomas Levine <_...@thomaslevine.com> wrote:
> On 22 Apr 15:38, Steve Schow wrote:
>> 3 - whether to
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
89 matches
Mail list logo
