Re: [fossil-users] Fossil-NG Bloat?

[Johan Kuuse]

On Thu, Nov 23, 2017 at 8:03 PM, Ron W  wrote:

> On Wed, Nov 22, 2017 at 7:09 PM,  fossil-scm.org> wrote:
>>
>> Date: Wed, 22 Nov 2017 19:09:21 -0500
>> From: Richard Hipp 
>> Subject: Re: [fossil-users] Fossil-NG Bloat?
>>
>> On 11/22/17, Offray Vladimir Luna Cárdenas  wrote:
>> > I'm dubious over making Fossil a client for
>> > any other main DVCS out there.
>>
>> One important reason that many people use Git is because so much OSS
>> is hosted on GitHub and everybody wants to be part of the action.  If
>> developer Alice wants to play in the OSS world, she has to use Git.
>> But if Fossil were able to clone, push, and pull from Git
>> repositories, that would enable Alice to use Fossil instead, opening
>> the door to wider adoption.
>>
>
> But we give up Fossil semantics. And some of git'd semantics will require
> extending the Fossil UI. And, if some of the UI ideas suggested would
> actually change (instead of extending) the behavior of existing Fossil
> commands. At that point, to my thinking, will be easier to use a proper git
> client rather than translate git commands to Fossil commands.
>
> Also, FWIW, it's been years since I last actually used git to "play in the
> Github world". The projects I have been contributing to accept patches just
> as readily as they accept pull requests, so I can just download a zip file,
> update the "vendor branch" in my Fossil repo for the project, make and test
> my changes, then make and send a patch.
>
> (Yes, many project only accept pull requests. Just been a long time since
> I've had a reason to contribute beyond a bug report (possibly including a
> tiny patch).)
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
I agree on that we would give up Fossil semantics.

I use Git on a daily basis at work, while I personally prefer Fossil, which
I always use for my own projects.
I can only speak for myself, but in the situation given to Alice, I would
still be using Git with .git repositories, and Fossil with .fossil
repositories.
One single reason is my FAQ to my colleagues: "How do I do this in Git?"
As I am lucky enough to have helpful colleagues, I sometimes even run some
advanced Git commands at work.

Imagine the following situation:
I would like check the history of my suddenly currupted git repository at
work, so 'git log' doesn't work as expected.
If I would have been Alice, I would have typed 'fossil timeline' but as I
only see weird output, I ask my colleague for help.
I bet that even the most helpfule colleague would answer: "Oh, you don't
use Git. Sorry, then you are on your own."


To me it's similar to the UNIX philosophy - keep it simple.
One tool should be really good at one thing, IMHO.

Let's compare with the 'sox' audio tool, which tries really hard to handle
all kind of existing file formats for audio.
Audio file formats are specified, fixed, and do not change over time.
In that case I think it is legitimate for a software project to try to be
"as universal as possible".

But repository formats are not audio formats, they change over time.
And what if, in the secret Git or Hg developer camp, someone is trying to
do a similar universal VCS container (including Fossil),
just to discover that the Fossil repository format has changed?
Maybe I am pessimistic about this, but maintaining up-to-date/in-sync new
features/formats continously developed in the Git and Hg (and SVN?)
community seems not only a daunting task,
but also a way of trying to reinventing the wheel. Why spend time on
porting Git/Hg features instead of creating new Fossil features?

Another doubt I have after reading this thread:

Sometimes I literally browse my repository/global settings/checkout DB, may
it be of curiosity, forgotten username, or just to learn a bit more of the
Fossil DB structure.
I think the third-party http://sqlitebrowser.org/ is just great for this
task.
Will that option get lost with the new repository format?

Best Regards,
Johan
___
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] Fossil-NG Bloat?

[Richard Hipp]

On 11/24/17, Johan Kuuse  wrote:
> I agree on that we would give up Fossil semantics.

I have no intent to "give up" or change the semantics of Fossil, and I
see no reason why enabling Fossil to push and pull from Git
repositories would require this.

Adding the ability to interact with Git is very much the same kind of
change as adding support for SHA3 hashes.  When Fossil 2.0 came out,
we didn't "give up" on the semantics of Fossil 1.37.  Most users
upgraded to Fossil 2.0 and never noticed any change at all.  Fossil
2.0 reads and writes legacy repos the same as it always did.  The only
thing that changed is that Fossil 2.0 also included the ability to
read/write repos that included artifacts with SHA3 hashes.  If none of
your repos have SHA3 hashes, then Fossil 1.37 and Fossil 2.0 are
completely interchangeable.  You only need Fossil 2.0 if you start
using repos that do include SHA3 hashes.

Likewise, moving from Fossil 2.x to Fossil-NG (whatever the version
number turns out to be) will be a non-issue for most users.  All the
commands will work the same when using legacy repos.  Fossil-NG merely
adds the ability to push and pull from Git.  If you don't use that
feature, then nothing changes.

Both Fossil 2.x and Fossil-NG will be able to read and write the same
Fossil repos, as long as you do not run use Fossil-NG features.  After
you "rebuild" and start using Fossil-NG specific features, legacy
Fossil-2.x clients might no longer work with that particular repo.
This is the same situation that came up in the Fossil-1.37 to
Fossil-2.0 transition.  That transition went smoothly and I expect the
transition to Fossil-NG to be just as smooth.
-- 
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] Clone a repo served by a winsrv service

[Stéphane Aulery]

Hello, 

Le 24/11/2017 08:16, Stephan Beal a écrit :

> On Fri, Nov 24, 2017 at 1:00 AM, Stéphane Aulery  wrote:
> 
>> Hello,
>> 
>> Yet an error form winsrv feature.
>> 
>> I try to clone a new repo and get this error :
>> 
>> $ fossil clone -v http://fossil/eulalia/ eulalia.fossil
>> Bytes  Cards  Artifacts Deltas
>> waiting for server...
>> getaddrinfo() fails: Hôte inconnu.
> 
> It cannot resolve the name "fossil" a your computer. What does "ping fossil" 
> (from a "cmd" window) say?

Thanks for you help. 

Maybe it's just I had to type fossil.local/... 

I can't test before 3 days. 

Regards, 

-- 
Stéphane Aulery___
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] Fossil-NG Bloat?

[Johan Kuuse]

On Fri, Nov 24, 2017 at 11:55 AM, Richard Hipp  wrote:
>
> On 11/24/17, Johan Kuuse  wrote:
> > I agree on that we would give up Fossil semantics.
>
> I have no intent to "give up" or change the semantics of Fossil, and I
> see no reason why enabling Fossil to push and pull from Git
> repositories would require this.

I think 'push' and 'pull' seems fair enough.
But what about 'rebase' and 'submodule'?
To what level should the Fossil-NG client support Git features not
present in Fossil?

If supported, wouldn't there be a risk of confusion when the user
wants to 'rebase'?
Even if commands such as 'pull' and 'pull' could be used
transparently, the user would have to take in consideration what kind
of backend is in use (Git or Fossil) before using 'rebase'.

If not supported, wouldn't there be a risk of users just sticking to
'git rebase' instead?


Sorry for not grasping the advantages about this idea.


>
> Both Fossil 2.x and Fossil-NG will be able to read and write the same
> Fossil repos, as long as you do not run use Fossil-NG features.  After
> you "rebuild" and start using Fossil-NG specific features, legacy
> Fossil-2.x clients might no longer work with that particular repo.
> This is the same situation that came up in the Fossil-1.37 to
> Fossil-2.0 transition.  That transition went smoothly and I expect the
> transition to Fossil-NG to be just as smooth.

Not a big deal, but will Fossil-NG repos be readable (the same way as
Fossil repos are) by sqlite3 from the command line?
(Currently I have a few scripts using that feature.)

Best Regards,
Johan
___
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] Fossil-NG Bloat?

[Richard Hipp]

On 11/24/17, Johan Kuuse  wrote:
>
> I think 'push' and 'pull' seems fair enough.
> But what about 'rebase' and 'submodule'?
> To what level should the Fossil-NG client support Git features not
> present in Fossil?

Zero.

>
> If not supported, wouldn't there be a risk of users just sticking to
> 'git rebase' instead?
>

If users want to rebase, then they can use their Git client.

-- 
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] A-B comparison of proposed timeline changes

[Richard Hipp]

Which is better?

  A:  https://www.fossil-scm.org/a/timeline
  B:  https://www.fossil-scm.org/b/timeline

Also:

  A: https://www.fossil-scm.org/a/finfo?name=src/search.c
  B: https://www.fossil-scm.org/b/finfo?name=src/search.c

Surf about from any of the links above for additional views.

The change here is to emphasis the check-in comment and de-emphasize
the links to the check-in details and other information.

In the recent HN discussion of Fossil
(https://news.ycombinator.com/item?id=15752725) some comments were
sharply critical of the timeline display in Fossil. While I think
those comments were overly dramatic, they did bring up the point that
the check-in comment is probably the most important feature and should
be more prominent.  This A/B comparison is my attempt to make them so.

Further suggestions and/or comments are welcomed.
-- 
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] A-B comparison of proposed timeline changes

[Stanislav Paskalev]

Hi,

I'd like to object the default use of low-contrast type in
professional software :)

I use displays that are adjusted for low eye strain by reducing
contrast and brightness. Having type and typography do the same thing
again has the opposite effect and legibility starts to suffer.

Regards,
Stanislav

Stanislav Paskalev


On Fri, Nov 24, 2017 at 4:35 PM, Richard Hipp  wrote:
> Which is better?
>
>   A:  https://www.fossil-scm.org/a/timeline
>   B:  https://www.fossil-scm.org/b/timeline
>
> Also:
>
>   A: https://www.fossil-scm.org/a/finfo?name=src/search.c
>   B: https://www.fossil-scm.org/b/finfo?name=src/search.c
>
> Surf about from any of the links above for additional views.
>
> The change here is to emphasis the check-in comment and de-emphasize
> the links to the check-in details and other information.
>
> In the recent HN discussion of Fossil
> (https://news.ycombinator.com/item?id=15752725) some comments were
> sharply critical of the timeline display in Fossil. While I think
> those comments were overly dramatic, they did bring up the point that
> the check-in comment is probably the most important feature and should
> be more prominent.  This A/B comparison is my attempt to make them so.
>
> Further suggestions and/or comments are welcomed.
> --
> 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] A-B comparison of proposed timeline changes

[j. van den hoff]

On Fri, 24 Nov 2017 15:35:55 +0100, Richard Hipp  wrote:


Which is better?

  A:  https://www.fossil-scm.org/a/timeline
  B:  https://www.fossil-scm.org/b/timeline

Also:

  A: https://www.fossil-scm.org/a/finfo?name=src/search.c
  B: https://www.fossil-scm.org/b/finfo?name=src/search.c

Surf about from any of the links above for additional views.

The change here is to emphasis the check-in comment and de-emphasize
the links to the check-in details and other information.

In the recent HN discussion of Fossil
(https://news.ycombinator.com/item?id=15752725) some comments were
sharply critical of the timeline display in Fossil. While I think
those comments were overly dramatic, they did bring up the point that
the check-in comment is probably the most important feature and should
be more prominent.  This A/B comparison is my attempt to make them so.

Further suggestions and/or comments are welcomed.


in my view, variant B might be preferable somewhat (for the GUI -- but  
leaving the timeline output in the terminal as is...). but choosing some  
pale color shades (or alpha?) makes the text difficult to read. I would  
prefer a smaller font instead, leaving the colors untouched.


personally, I rather like the tidiness of the timeline graph available in  
mercurial via `hg serve' which beyond the checkin message hides everything  
except time of checkin, branch name, and user (and uses a distinctly  
smaller font size for the latter info). in effect one mostly notices the  
checkin message easily. so one might think about doing something similar  
(remove hash display and link the commit message itself to the 'chekin'  
page)?


just an idea


--
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] A-B comparison of proposed timeline changes

[Richard Hipp]

On 11/24/17, Richard Hipp  wrote:
> Which is better?
>
>   A:  https://www.fossil-scm.org/a/timeline
>   B:  https://www.fossil-scm.org/b/timeline
>

Alternative CSS that causes the "details" to appears on a separate
line from the comment:

A:  https://sqlite.org/src/timeline
B:  https://sqlite.org/b/timeline

-- 
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] A-B comparison of proposed timeline changes

[Richard Hipp]

On 11/24/17, j. van den hoff  wrote:
>
> personally, I rather like the tidiness of the timeline graph available in
> mercurial via `hg serve' ... so one might think about doing something similar
> (remove hash display and link the commit message itself to the 'chekin'
> page)?

Fossil has the ability to include links within a check-in message - a
feature that SQLite uses quite a bit.  See, for example, the
hyperlinks embedded within the check-in comments for the first few
items on https://sqlite.org/b/timeline?y=ci

If the entire check-in comment is a hyperlink, that would make it
difficult to have hyperlinks embedded within the check-in comment.

-- 
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] A-B comparison of proposed timeline changes

[Lutz Horn]

Am 24.11.17 um 16:17 schrieb Richard Hipp:
> If the entire check-in comment is a hyperlink, that would make it
> difficult to have hyperlinks embedded within the check-in comment.

I totally agree. So far I only use ticket IDs that are automatically
linked but this is very important to me. If the whole commit ci comment
would be linked, this would not be possible.

Lutz
___
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] A-B comparison of proposed timeline changes

[Andy Bradford]

Thus said Richard Hipp on Fri, 24 Nov 2017 09:35:55 -0500:

> Which is better?
> 
>   A:  https://www.fossil-scm.org/a/timeline
>   B:  https://www.fossil-scm.org/b/timeline

I prefer  A. I don't  like muted colors for  text. I prefer  seeing text
than to  have to  look for  text that begins  to blend  with surrounding
colors.

Andy
-- 
TAI64 timestamp: 40005a183ed0


___
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] A-B comparison of proposed timeline changes

[Andy Bradford]

Thus said Richard Hipp on Fri, 24 Nov 2017 09:35:55 -0500:

> The change here  is to emphasis the check-in  comment and de-emphasize
> the links to the check-in details and other information.

Hopefully this  change is  simply accomplished with  some CSS.  That way
those who prefer their UI to  make text blend in with surrounding colors
can do so. :-)

Andy
-- 
TAI64 timestamp: 40005a183f98


___
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] A-B comparison of proposed timeline changes

[Andy Bradford]

Thus said Richard Hipp on Fri, 24 Nov 2017 10:13:22 -0500:

> Alternative CSS that causes the "details" to appears on a separate
> line from the comment:
> 
> A:  https://sqlite.org/src/timeline
> B:  https://sqlite.org/b/timeline

I think  it looks slightly  cleaner with  the ``details'' on  a separate
line, however, I still miss the Leaf, which I do find useful.

Leaving out  the node  status information  does make  it read  more like
prose and  look less like  a tree  structure, however, maybe  some don't
find it useful to know what kind of a node it is.

Andy
-- 
TAI64 timestamp: 40005a184102


___
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] A-B comparison of proposed timeline changes

[Richard Hipp]

On 11/24/17, Andy Bradford  wrote:
> Thus said Richard Hipp on Fri, 24 Nov 2017 09:35:55 -0500:
>
>> The change here  is to emphasis the check-in  comment and de-emphasize
>> the links to the check-in details and other information.
>
> Hopefully this  change is  simply accomplished with  some CSS.  That way
> those who prefer their UI to  make text blend in with surrounding colors
> can do so. :-)

The movement of the check-in hash from in front of the check-in
comment until after the check-in comment is a code change.  I suppose
it could be made a configuration parameter, such as the choice between
round or square nodes in the graph.  But text movement like that is
not something I know how to do in CSS.

The graying of text after the check-in comment *is* accomplished using
CSS.  That can be changed easily.  I have a slightly different CSS
over at https://sqlite.org/b/timeline that puts the "detail"
information on a separate line.  It is still slightly grayed, though.
I took my cue on the graying of less-relevant text from Google search
result screens, which do the same thing.

-- 
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] A-B comparison of proposed timeline changes

[Richard Hipp]

On 11/24/17, Andy Bradford  wrote:
> I still miss the Leaf, which I do find useful.

Ugh.  I didn't intend to omit the "Leaf" and "Closed-Leaf" marks,
though I did want to move them to the end, rather than before the
check-in comment.  The omission of that information is a bug.

-- 
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] A-B comparison of proposed timeline changes

[Richard Hipp]

On 11/24/17, Richard Hipp  wrote:
> On 11/24/17, Andy Bradford  wrote:
>> I still miss the Leaf, which I do find useful.
>
> Ugh.  I didn't intend to omit the "Leaf" and "Closed-Leaf" marks,
> though I did want to move them to the end, rather than before the
> check-in comment.  The omission of that information is a bug.

Now fixed.

Other changes on https://www.fossil-scm.org/b/timeline since the
original comparison request:

  (1)  The "details" section is shown on a separate line below the
check-in comment.
  (2)  The "details" are in the same font-color as the comment-text
but have a slightly reduced font size.

-- 
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] Fossil-NG Bloat?

[j. van den hoff]

On Fri, 24 Nov 2017 15:25:25 +0100, Richard Hipp  wrote:


On 11/24/17, Johan Kuuse  wrote:


I think 'push' and 'pull' seems fair enough.
But what about 'rebase' and 'submodule'?
To what level should the Fossil-NG client support Git features not
present in Fossil?


Zero.


a good thing in my view ... but, consequently, users will run into the  
"impedance mismatch" problem between the different systems mentioned by  
several others, no?






If not supported, wouldn't there be a risk of users just sticking to
'git rebase' instead?



If users want to rebase, then they can use their Git client.


as they could for the rest of their interaction with the git repo. I  
presume exactly that will happen: existing primary git users won't switch  
to a different "git client" anyway. fossil users probably _would_ use the  
ability of fossil-NG to talk to a git repo, though, as long as they don't  
need to do git-specific fancy stuff. but I question whether implementing  
this ability could increase the user base notably.







--
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] A-B comparison of proposed timeline changes

[bch]

On Fri, Nov 24, 2017 at 8:12 AM Richard Hipp  wrote:

> On 11/24/17, Richard Hipp  wrote:
> > On 11/24/17, Andy Bradford  wrote:
> >> I still miss the Leaf, which I do find useful.
> >
> > Ugh.  I didn't intend to omit the "Leaf" and "Closed-Leaf" marks,
> > though I did want to move them to the end, rather than before the
> > check-in comment.  The omission of that information is a bug.
>
> Now fixed.
>
> Other changes on https://www.fossil-scm.org/b/timeline since the
> original comparison request:
>
>   (1)  The "details" section is shown on a separate line below the
> check-in comment.
>   (2)  The "details" are in the same font-color as the comment-text
> but have a slightly reduced font size.
>

I don’t see that reflected on the link. Perhaps consider a .gif snapshot of
the effects so it’s not subject to code change on a live system, and
annotatable if necessary?



> --
> 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] A-B comparison of proposed timeline changes

[Richard Hipp]

On 11/24/17, bch  wrote:
>>
>>   (1)  The "details" section is shown on a separate line below the
>> check-in comment.
>>   (2)  The "details" are in the same font-color as the comment-text
>> but have a slightly reduced font size.
>>
>
> I don’t see that reflected on the link.

Those are CSS changes.  So you will need to press "Reload" in your
browser, possibly multiple times if you use Chrome, before you will be
able to see the changes.

-- 
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] A-B comparison of proposed timeline changes

[sky5walk]

I understand the need for links, but do users really need truncated hashes
for every line?
Can the link be applied more subtly?
Can there be a similar "quiet" setting for the Timeline like *Per-Item Time
Format = (off) *to conserve space?
My commits prepend a simple timestamp in the comment and multiline text for
more immediate descriptions right up front.
Having this tail every entry -> (check-in: [4dfa592f]
 user: drh

 tags: trunk
)
<-
makes the timeline quite busy.

Thanks for Fossil!

On Fri, Nov 24, 2017 at 11:27 AM, Richard Hipp  wrote:

> On 11/24/17, bch  wrote:
> >>
> >>   (1)  The "details" section is shown on a separate line below the
> >> check-in comment.
> >>   (2)  The "details" are in the same font-color as the comment-text
> >> but have a slightly reduced font size.
> >>
> >
> > I don’t see that reflected on the link.
>
> Those are CSS changes.  So you will need to press "Reload" in your
> browser, possibly multiple times if you use Chrome, before you will be
> able to see the changes.
>
> --
> 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] A-B comparison of proposed timeline changes

[David Mason]

I like the B cases... in fact I'd indent the details a bit so that the
comments are easier to find visually.

On 24 November 2017 at 11:53,  wrote:

> I understand the need for links, but do users really need truncated hashes
> for every line?
> Can the link be applied more subtly?
> Can there be a similar "quiet" setting for the Timeline like *Per-Item
> Time Format = (off) *to conserve space?
> My commits prepend a simple timestamp in the comment and multiline text
> for more immediate descriptions right up front.
> Having this tail every entry -> (check-in: [4dfa592f]
>  user: drh
> 
>  tags: trunk
> )
> <-
> makes the timeline quite busy.
>
> Thanks for Fossil!
>
> On Fri, Nov 24, 2017 at 11:27 AM, Richard Hipp  wrote:
>
>> On 11/24/17, bch  wrote:
>> >>
>> >>   (1)  The "details" section is shown on a separate line below the
>> >> check-in comment.
>> >>   (2)  The "details" are in the same font-color as the comment-text
>> >> but have a slightly reduced font size.
>> >>
>> >
>> > I don’t see that reflected on the link.
>>
>> Those are CSS changes.  So you will need to press "Reload" in your
>> browser, possibly multiple times if you use Chrome, before you will be
>> able to see the changes.
>>
>> --
>> D. Richard Hipp
>> d...@sqlite.org
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] A-B comparison of proposed timeline changes

[Jacob MacDonald]

Seems like I'm in the minority, but I prefer the A version. I tend to like
compact UIs and having all the relevant information close together and the
commit hash prominently displayed is nice.

On Fri, Nov 24, 2017 at 12:32 PM David Mason  wrote:

> I like the B cases... in fact I'd indent the details a bit so that the
> comments are easier to find visually.
>
> On 24 November 2017 at 11:53,  wrote:
>
>> I understand the need for links, but do users really need truncated
>> hashes for every line?
>> Can the link be applied more subtly?
>> Can there be a similar "quiet" setting for the Timeline like *Per-Item
>> Time Format = (off) *to conserve space?
>> My commits prepend a simple timestamp in the comment and multiline text
>> for more immediate descriptions right up front.
>> Having this tail every entry -> (check-in: [4dfa592f]
>>  user: drh
>> 
>>  tags: trunk
>> )
>> <-
>> makes the timeline quite busy.
>>
>> Thanks for Fossil!
>>
>> On Fri, Nov 24, 2017 at 11:27 AM, Richard Hipp  wrote:
>>
>>> On 11/24/17, bch  wrote:
>>> >>
>>> >>   (1)  The "details" section is shown on a separate line below the
>>> >> check-in comment.
>>> >>   (2)  The "details" are in the same font-color as the comment-text
>>> >> but have a slightly reduced font size.
>>> >>
>>> >
>>> > I don’t see that reflected on the link.
>>>
>>> Those are CSS changes.  So you will need to press "Reload" in your
>>> browser, possibly multiple times if you use Chrome, before you will be
>>> able to see the changes.
>>>
>>> --
>>> D. Richard Hipp
>>> d...@sqlite.org
>>> ___
>>> fossil-users mailing list
>>> fossil-users@lists.fossil-scm.org
>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>>
>>
>>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
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] A-B comparison of proposed timeline changes

[Martin Gagnon]

On Fri, Nov 24, 2017 at 06:52:41PM +, Jacob MacDonald wrote:
> Seems like I'm in the minority, but I prefer the A version. I tend to like
> compact UIs and having all the relevant information close together and the
> commit hash prominently displayed is nice.

   

Same for me. 

With B version, checkin hash links are not aligned, so it's
not as natural when it's time to click on them, I have to find the link
at the end of the comment.

Moreover, when the comment wraps on multiple lines, a quick look make it
looks like 2 separate checkins. It's not the case with A version because
a new checkin start with the hash link.

Regards

-- 
Martin G.
___
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] A-B comparison of proposed timeline changes

[Zakero]

Looking at the commit message data, it has a 4 types of information:
- The check-in link
- The commit message
- Leaf, Closed-Leaf
- Detail (user, tags)

For me, the most important piece of information is the check-in link.  Now,
l have to search for the link because it is no longer in a consistent
location.
The commit message is next.  Since the check-in link was usually the same
length, the commit message starts in the same the same location for each
timeline node for either format change.  My commit messages range from 1 to
15 lines and I like to see the full commit message in the timeline (Allow
block-markup in timeline = Enabled, Truncate comment at first blank line =
Disabled)  So the end of my commit messages varies quite a bit in the
timeline.
Leaf status and Details have not been that important to me, since that
information can be viewed more clearly in other parts of fossil when needed.

And yes, I know that I can click on the "time" to get to the check-in page
with the new changes, but that is another non-obvious / counter-intuitive
addition of the fossil UI.  (The more famous being the "click on the
timeline nodes to see a diff")

tldr; This new change of the timeline makes it harder to find useful links.
___
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] fossil-users Digest, Vol 118, Issue 35

[Ron W]

On Fri, Nov 24, 2017 at 10:17 AM,  wrote:
>
> Date: Fri, 24 Nov 2017 09:35:55 -0500
> From: Richard Hipp 
> Subject: [fossil-users] A-B comparison of proposed timeline changes
>
> Which is better?
>
>   A:  https://www.fossil-scm.org/a/timeline
>   B:  https://www.fossil-scm.org/b/timeline


I prefer B because I don't have to scroll down to get to the "older" link.

I do like having the timestamp of the commit as the link to the commit.

Also, I did not see any effect when adding the "?basic=1" option to the URL.
___
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] Fossil-NG Bloat?

[Ron W]

On Fri, Nov 24, 2017 at 7:00 AM, 
wrote:
>
> Date: Fri, 24 Nov 2017 05:55:51 -0500
> From: Richard Hipp 
> Subject: Re: [fossil-users] Fossil-NG Bloat?
>
> On 11/24/17, Johan Kuuse  wrote:
> > I agree on that we would give up Fossil semantics.
>
> I have no intent to "give up" or change the semantics of Fossil, and I
> see no reason why enabling Fossil to push and pull from Git
> repositories would require this.
>

Your wiki page summary and replies in this discussion imply you would
implement interoperability with git by having fossil store git artifacts.

Between your comments that git/Fossil artifact translation has significant
overhear (and a claim that "git fast-export | (cd /new/path; git
fast-import)" is not lossy), there is an implication that git artifacts do
not support all of Fossil's metadata.

What effect will this reduced metadata have on applying Fossil semantics to
git artifacts?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] A-B comparison of proposed timeline changes

[Richard Hipp]

On 11/24/17, Zakero  wrote:
>
> tldr; This new change of the timeline makes it harder to find useful links.
>

There is now a per-repository configuration option under
Setup/Timeline that lets you choose which timeline format you prefer.

https://www.fossil-scm.org/fossil/ is currently configured so that
when you click on the "Timeline" menu, you get
https://www.fossil-scm.org/fossil/timeline?basic - the "basic" query
parameter declutters the display as much as possible to be friendly to
newbies.  You can change this on your repos by searching for
"/timeline?basic" in your "Header" configuration and omitting the
query parameter.

There is an undocumented query parameter on /timeline that lets you
experiment with different formatting options without having to change
the configuration.

   https://www.fossil-scm.org/fossil/timeline?commentformat=1
   https://www.fossil-scm.org/fossil/timeline?commentformat=2
   https://www.fossil-scm.org/fossil/timeline?commentformat=3
   https://www.fossil-scm.org/fossil/timeline?commentformat=4
   https://www.fossil-scm.org/fossil/timeline?commentformat=5
   https://www.fossil-scm.org/fossil/timeline?commentformat=12

The "basic" query parameter simply forced commentformat=5 and then
disables a lot of the complex submenu controls, replacing them all
with an "Advanced" button that turns "basic" off.

Other values for commentformat=N are possible, but are reserved for
future expansion.

Thanks to everyone who contributed comments!  All suggestions were
useful, even those that I did not implement.  It is important to have
lots of ideas in circulation.

One thing I learned from this exercise is that no two people want the
timeline to look the same way.   Consensus is not a possibility here.
There is too much diversity of opinion. Therefore, I had to exercise
my authority as the BDFL and pick one particular behavior for the
canonical Fossil repo and to be the default.  You are welcomed to pick
a different behavior for your own repositories, since it is now
configurable.
-- 
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] Fossil-NG Bloat?

[Richard Hipp]

On 11/24/17, Ron W  wrote:
>
> Your wiki page summary and replies in this discussion imply you would
> implement interoperability with git by having fossil store git artifacts.

I don't know yet if it would be better to store Git artifacts
natively, or to translate them into Fossil artifacts.  The final
implementation might do either.  Or both.  We'll just have to wait and
see.

>
> Between your comments that git/Fossil artifact translation has significant
> overhear (and a claim that "git fast-export | (cd /new/path; git
> fast-import)" is not lossy), there is an implication that git artifacts do
> not support all of Fossil's metadata.
>
> What effect will this reduced metadata have on applying Fossil semantics to
> git artifacts?
>

Git artifacts do not support named branches, the ability to edit a
check-in comment, the ability to edit a check-in date/time, wiki, nor
tickets.  So if you do any of those things, they won't push back up to
the Git repo to which you are syncing.

I suppose that if Fossil knows that it is syncing with Git and you try
to do any of those things (and perhaps other stuff I haven't yet
thought of) then Fossil should show a scary warning to the effect that
"If you do this, the result of your actions will not be pushable to
Git - are you sure you want to continue?"

-- 
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] A-B comparison of proposed timeline changes

[sky5walk]

Wow, #5 is super clean and easy on the eyes!
And #12 is interesting if I can see it with Per-Item Time Format = (off)?

Thanks for the changes!

On Fri, Nov 24, 2017 at 7:12 PM, Richard Hipp  wrote:

> On 11/24/17, Zakero  wrote:
> >
> > tldr; This new change of the timeline makes it harder to find useful
> links.
> >
>
> There is now a per-repository configuration option under
> Setup/Timeline that lets you choose which timeline format you prefer.
>
> https://www.fossil-scm.org/fossil/ is currently configured so that
> when you click on the "Timeline" menu, you get
> https://www.fossil-scm.org/fossil/timeline?basic - the "basic" query
> parameter declutters the display as much as possible to be friendly to
> newbies.  You can change this on your repos by searching for
> "/timeline?basic" in your "Header" configuration and omitting the
> query parameter.
>
> There is an undocumented query parameter on /timeline that lets you
> experiment with different formatting options without having to change
> the configuration.
>
>https://www.fossil-scm.org/fossil/timeline?commentformat=1
>https://www.fossil-scm.org/fossil/timeline?commentformat=2
>https://www.fossil-scm.org/fossil/timeline?commentformat=3
>https://www.fossil-scm.org/fossil/timeline?commentformat=4
>https://www.fossil-scm.org/fossil/timeline?commentformat=5
>https://www.fossil-scm.org/fossil/timeline?commentformat=12
>
> The "basic" query parameter simply forced commentformat=5 and then
> disables a lot of the complex submenu controls, replacing them all
> with an "Advanced" button that turns "basic" off.
>
> Other values for commentformat=N are possible, but are reserved for
> future expansion.
>
> Thanks to everyone who contributed comments!  All suggestions were
> useful, even those that I did not implement.  It is important to have
> lots of ideas in circulation.
>
> One thing I learned from this exercise is that no two people want the
> timeline to look the same way.   Consensus is not a possibility here.
> There is too much diversity of opinion. Therefore, I had to exercise
> my authority as the BDFL and pick one particular behavior for the
> canonical Fossil repo and to be the default.  You are welcomed to pick
> a different behavior for your own repositories, since it is now
> configurable.
> --
> 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] Fossil-NG ideas

[Ron W]

On Tue, Nov 21, 2017 at 6:43 PM, 
wrote:
>
> Date: Tue, 21 Nov 2017 15:25:37 -0700
> From: Warren Young 
> Subject: Re: [fossil-users] Fossil-NG ideas
>
> On Nov 21, 2017, at 2:09 PM, Ron W  wrote:
> >
> > While I like the idea of a "smart default" for the file name, I'd rather
> have an "--open" (or "-o") option to trigger the automatic "fossil open”.
>
> So…you want to remain more difficult to use than Git in this regard?
>

"fossil clone -o URL" would still be 1 step instead of 4 steps.


> > 1. If the user actually wants to specify the name, the option would be
> needed, anyway.
>
> No, they’d pass the FILENAME argument to “fossil clone,” just as you do
> today.
>

My understanding of your proposal was that leaving off the file name would
be the trigger for the git-like behavior.

So, I would expect "fossil clone URL filename" to do what it does today:
Create a repository file with the specified filename. No more.


> This does open a new issue, however.  What does this mean:
>
> $ fossil clone https://fossil-scm.org/ fsl
>
> Do you:
>
> a) get a fsl subdirectory containing the contents of the Fossil trunk
> checkout, as Git would do; or
>
> b) get a fsl.fossil file, as someone up-thread apparently wants.  That is,
> assume the FILENAME argument is still a repository file name, and that if
> .fossil is not given as an extension, add it?  Or
>
> c) get a fsl file, as Fossil 2.4 and all prior versions do?


I would expect c - do as Fossil does, today.

If I want the git-like behavior, I'd type "fossil clone -o
https://fossil-scm.org/ fsl"

I'm all for "stealing" features from other VCSs. Just don't change break
existing command syntax.

As for something I'd suggest stealing, how about enhancing "fossil
checkout" to accept an optional URL?

When I first started using Fossil, one of the things that was confusing to
me is that "svn checkout" maps to "fossil open", not "fossil checkout". It
is still something I help others migrating from SVN to Fossil. If Fossil
did not have a checkout command, it would have been less confusing. What I
tell those I help is "Just use 'fossil open' and pretend there is no
'fossil checkout'."

Anyway, "fossil checkout" could be made more like "svn checkout" merely by
extending the syntax to allow an optional URL.
___
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] fossil-users Digest, Vol 118, Issue 38

[Ron W]

On Fri, Nov 24, 2017 at 7:19 PM, 
wrote:
>
> Date: Fri, 24 Nov 2017 19:19:27 -0500
> From: Richard Hipp 
> To: "Fossil SCM user's discussion" 
> Subject: Re: [fossil-users] Fossil-NG Bloat?
> Message-ID:
>  ah...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On 11/24/17, Ron W  wrote:
> > What effect will this reduced metadata have on applying Fossil semantics
> to
> > git artifacts?
> >
>
> Git artifacts do not support named branches, the ability to edit a
> check-in comment, the ability to edit a check-in date/time, wiki, nor
> tickets.  So if you do any of those things, they won't push back up to
> the Git repo to which you are syncing.
>
> I suppose that if Fossil knows that it is syncing with Git and you try
> to do any of those things (and perhaps other stuff I haven't yet
> thought of) then Fossil should show a scary warning to the effect that
> "If you do this, the result of your actions will not be pushable to
> Git - are you sure you want to continue?"
>

I suppose artifact types git doesn't support could simply not be pushed.

As I recall, a "git push" only pushes a single branch (master by default),
so how Fossil stores branches would be irrelevant to git.

However, specifically to Github:

Github states it stores wiki pages in a sperate, parallel git repo. The
format is "reponame.wiki.git". So, Fossil could pull/push from/to both git
repos when dealing with Github. Again, how Fossil stores wiki pages would
not matter.

Tickets (including pull requests) on Github appear to be stored in a
separate database. Github calls them "issues". Not sure of the effort
required to maintain and synchronize a local copy of Github issues.

I have not looked at how other Github-like services handle wiki pages and
tickets.
___
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] A-B comparison of proposed timeline changes

[Jungle Boogie]

On Fri 24 Nov 2017  7:25 PM, sky5w...@gmail.com wrote:
> Wow, #5 is super clean and easy on the eyes!
> And #12 is interesting if I can see it with Per-Item Time Format = (off)?
> 
> Thanks for the changes!

#5 is nice, and especially with the easy option to switch back to
advanced. Perhaps the basic option can include the user as well, that
would probably be my only suggestion.

DRH, thank you for being so willing to listen to the user base and those
who have probably never touched fossil before (such as HN folks).
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users