add option to display unified or sidebyside patch by default too
Enviado con Aquamail para Android
http://www.aqua-mail.com
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
OK, thanks to John I learnt in my other thread [1] that this can be achieved
via Admin/Skins/Headers.
[1] http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg22970.html
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
Hi John,
On 24 Apr 2016, at 01:45 , John P. Rouillard wrote:
> You're missing what he is saying. He is saying change the Timeline
> (/timeline) link in the menu.
indeed, not hard to miss it. :)
I couldn’t figure out where I could change exactly those links.
Now I see
In message ,
=?iso-8859-1?Q?Marko_K=E4ning?= writes:
>
>On 24 Apr 2016, at 01:07 , Stephan Beal wrote:
>
>> You need to edit the links in the menus to add parameters for the
>> settings you want. e.g. max is set using n=123.
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:
> -
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
On 24 Apr 2016, at 01:07 , Stephan Beal wrote:
> You need to edit the links in the menus to add parameters for the settings
> you want. e.g. max is set using n=123.
>
I know that I can do that, in principle, BUT next time I click the /timeline
menu link I am back to
You need to edit the links in the menus to add parameters for the settings
you want. e.g. max is set using n=123.
- stephan
(Sent from a mobile device, possibly from bed. Please excuse brevity,
typos, and top-posting.)
On Apr 24, 2016 01:02, "Marko Käning" wrote:
Perhaps it is important to note that I am running the current stable version
1.34,
which I had posted only in my 1st post to the list today:
> I’ve installed fossil’s version 1.34 using MacPorts on OSX. The web UI shows
> this version string:
>
> Fossil version [62dcb00e68] 2015-11-02
My /setup_timeline page gives me these options:
Allow block-markup in timeline
Plaintext comments on timelines
Use Universal Coordinated Time (UTC)
Per-Item Time Format
Show version differences by default
Max timeline comment length
which do not include the 3 additional ones I am seeking
Hi Stephan,
On 24 Apr 2016, at 00:49 , Stephan Beal wrote:
> All 3 of those options are there, but i am in bed and won't be up for
> (ideally) another 10 hours, so i am hoping someone else will point them out
> ;). Help is not in the default menu because it is, in
All 3 of those options are there, but i am in bed and won't be up for
(ideally) another 10 hours, so i am hoping someone else will point them out
;). Help is not in the default menu because it is, in practice, rarely
used. Feel free to add it to yours.
- stephan
(Sent from a mobile device,
On 24 Apr 2016, at 00:25 , Stephan Beal wrote:
> Ps: see the /help page for the various /timeline options.
>
Well, this allows a couple of settings, yes, but not the three I asked for:
> • Timeline view:
> - Type of entries (e.g. only check-ins)
> - Max.
>
Hi Sephan,
On 24 Apr 2016, at 00:23 , Stephan Beal wrote:
> You can achieve all of that by changing the appropriate menu entries/links
> via the setup page. If
>
I am puzzled, as I can’t seem to find the correct setup page which makes the
wiki’s menu links
available
Ps: see the /help page for the various /timeline options.
- stephan
(Sent from a mobile device, possibly from bed. Please excuse brevity,
typos, and top-posting.)
On Apr 24, 2016 00:23, "Stephan Beal" wrote:
> You can achieve all of that by changing the appropriate
You can achieve all of that by changing the appropriate menu entries/links
via the setup page. If
- stephan
(Sent from a mobile device, possibly from bed. Please excuse brevity,
typos, and top-posting.)
On Apr 24, 2016 00:19, "Marko Käning" wrote:
> Hi,
>
> it
Hi,
it would be nice to have some default settings definable for a user:
• Timeline view:
- Type of entries (e.g. only check-ins)
- Max.
- With/Without Files
• Files view:
- would be nice to be able to set it e.g. by default to tree-view.
This would be probably ideally
Hi,
is it possible to define code-blocks which
1) have extra vertical space for better separation
in paragraphs or stg like list items?
2) have perhaps even a frame around them?
I guess this all could be achieved by some CSS magic,
but I think it would be nice to have that as
On 23 Apr 2016, at 23:39 , Stephan Beal wrote:
> It can only amend new info to a ticket, not replace anything.
OK, that makes sense, yes. Thanks for the pointer!
I see now that it also says “Append Remark with format” in the edit dialog page
for the field which I
Hi devs,
why do the font sizes in fossil's wiki rendering (for code snippets)
aren't really nicely matching the text flow?
If I want to render a code snippet with apostrophes like `this snippet`,
then the font used for text “this snippet” would be only 75% the size I’d
expect it to have to
Hi devs,
if the search feature is enabled the [Wiki](/wiki) and [Tickets](/ticket) views
show at first the search edit field instead of the list of available wiki/ticket
overview pages, which would make more sense - so I believe...
One could also think about having the search edit field together
On Sat, Apr 23, 2016 at 11:30 PM, Marko Käning
wrote:
> For some reason fossil's ticket edit dialog page
> (/tktedit?name=ARTIFACTID)
> seems broken, as it doesn't show the actual ticket comment which had been
> entered previously by its creator.
>
> However,
Hi folks,
---
>First of all< I want to say that I am delighted with this SCM system,
after having used CVS, SVN, Mercurial and Git for quite some time...
I’ve liked to use Mercurial with the b extension to keep my bugs in
source control together with the code...
... but
Hi Richard,
ok, fair enough, I will use the mailing list then. Thanks!!
Greets,
Marko
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On 4/23/16, Marko Käning wrote:
> Hi,
>
> I am new to fossil and thought that I could file a ticket at fossil’s ticket
> tracker.
>
> I logged on as “anonymous”, as suggested by the wiki, but there is no button
> for creating a new ticket.
>
> What should I do
Hi,
I am new to fossil and thought that I could file a ticket at fossil’s ticket
tracker.
I logged on as “anonymous”, as suggested by the wiki, but there is no button
for creating a new ticket.
What should I do instead?
Greets,
Marko
___
Thus said Steve Schow on Fri, 22 Apr 2016 23:04:57 -0600:
> 1 - step#4 is fine because dev is working on a branch. do you have any
> mechanisms in place to prevent them from accidentally committing a
> file on the trunk instead of the branch at this stage of the workflow?
There is nothing
On Sat, Apr 23, 2016 at 12:26 PM, Steve Schow wrote:
> it sounds to me like your repos are backed up well as long as they are all
> completely sync’d with each other on a regular basis and so long as they
> are located on different HDD volumes and at least one copy offsite from
it sounds to me like your repos are backed up well as long as they are all
completely sync’d with each other on a regular basis and so long as they are
located on different HDD volumes and at least one copy offsite from one of the
other copies. Your versioning history is very well backed up
On 4/23/16, Steve Schow wrote:
>
> version control is definitely not a backup ...
>
Why not? What am I missing?
For Fossil and for SQLite, our "backup" is 3 copies of the
repositories for each project, running in three different datacenters,
using two separate providers, plus
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
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
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
On Fri, Apr 22, 2016 at 11:45 PM, Arnel wrote:
>
>
> Doesn't working on a branch marked private and merging it later (upon
> approval)
> essentially provide the benefits of "squashing" the commits? The only
> difference
> would be the branch commits themselves will not be
On Sat, Apr 23, 2016 at 2:06 AM, Steve Schow wrote:
>
>
> if so, not a big deal then, just have to use wrapper scripts to make sure
> to follow your work flow, always create a new branch on the first commit
> for any ticket. I will probably use a cookie or something to make
On Sat, Apr 23, 2016 at 1:04 AM, Steve Schow wrote:
>
> Nice work flow…
>
Thanks. It is simplified to highlight the key parts.
> In the above workflow, here are my questions:
>
> 1 - step#4 is fine because dev is working on a branch. do you have any
> mechanisms in place to
On Sat, Apr 23, 2016 at 12:06 AM, Steve Schow wrote:
>
> 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
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
38 matches
Mail list logo