Re: [fossil-users] remote check in

[Andy Bradford]

Thus said Scott Doctor on Sat, 22 Oct 2016 15:40:33 -0700:

> The problem I am having is how to add files, do check-ins and such via
> the  UI,  mostly regarding  doing  it  remotely without  command  line
> access.

It isn't possible to commit files to the repository using the Fossil UI.

This is  also true for svn,  git, and most other  repositories. There do
exist tools  that wrap the commands  in a UI. For  example, TortoiseSVN,
TortoiseGit, etc.

I believe I have seen someone announce on this list a wrapper UI for the
Fossil commands. Maybe search the archives?

Hope this helps.

Thanks,

Andy
-- 
TAI64 timestamp: 4000580c252e


___
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] Broke repository using command line.

[Venkat Iyer]

Thanks for the reply Andy.   I tried to keep you anonymous ). I had to
fix
it last night.  I ended up doing this:

1. a fossil decostruct,
2. grepped through the files for +icomment,
3. deleted the file with that in it
4. fossil reconstruct
5. fossil sqlite3 hackery to restore project id
6. fossil sync into an existing mirror (to push the few hours of updates,
maybe optional)
7. fossil config pull all (to get users ticket changes etc).
8. Told everyone (who checked directly out of master db) to
8.1. fossil close -f,
8.2. fossil open  x.fossil  -keep
8.3. fossil status -sha1sum
8.4. fossil update

Then I got to ok-enough-to-go-to-sleep state.

Seems to be holding up so far.

Thanks for taking the time to reply on the chat and finding a workaround
here.   I missed cc'ing the group in my laste email.


On Sat, Oct 22, 2016 at 12:31 PM, Andy Bradford 
wrote:

> Thus said Venkat Iyer on Fri, 21 Oct 2016 21:39:11 -0700:
>
> > The  icomment stuff  must have  recently changed.  "User Comments"  is
> > different than  "comments". I used  to do  +comments and that  used to
> > append to the end of the ticket before. But if I do that now, it shows
> > up  *before*  the  user  comments  entered  from  the  web,  which  is
> > confusing.
>
> I don't know as  much about the ticketing system so I  don't know how it
> used  to work,  but  perhaps someone  who  uses it  can  comment on  the
> difference between comment/icomment and what they mean.
>
> > So based on  someone's advice on the  tcl chat I did  icomments. But I
> > mistakenly added a + though apparently I shouldn't have.
>
> I was  the one who  suggested using  icomment because that  ``worked for
> me'' but perhaps it was the wrong  thing to begin with. Maybe the bug is
> that +comment  doesn't do what it  used to do and  icomment shouldn't be
> used, or its use is different than expected.
>
> Apologies for misleading you and getting your repo in a bad state. :-)
>
> Thanks,
>
> Andy
> --
> TAI64 timestamp: 4000580bbeab
>
>
>
___
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] OT: Why we should NEVER use inetd/xinetd

[Nathaniel Reindl]

> On Oct 22, 2016, at 17:23, K. Fossil user  
> wrote:
> P.S. : I will never understand why people don't know about security issue 
> when it comes to inetd.

Aha, so this was a security concern. I figured just as much. Please read on. (:

> I was explained to never use ONE daemon for many servers. When needed ONE 
> daemon for ONE server and not more.

OK, so, from a systems design standpoint, inetd and xinetd don't inherently 
have insecure designs as super servers. Instead, that design lends them a 
tendency to exhibit pathological unreliability; if inetd or xinetd crash (say, 
because the configuration parser has a bug because it unwittingly derefs NULL), 
the services that are run under the auspices of either one will similarly meet 
a less than pleasant fate.

The security concerns come in as a result of not paying attention to the 
details of the implementation. Make sure you use things like initgroups(3), 
setgid(2), and setuid(2) to drop privileges. Make sure you understand how 
inter-process communication can be made secure. Make sure you have good hygiene 
when you dynamically allocate memory and work with, e.g., NUL-terminated 
strings.

Now, it just so happens that it's simpler to keep track of the security details 
in things like tcpserver and tcpsvd because the 
single-instance-per-single-server architecture lends itself well to fewer lines 
of code to serve as a liability, but that is by no means a guarantee. Caveat 
emptor.

> 2/ Xinetd is old (four years ?) so may be not secure.

xinetd is actually older than that. It may have not, for whatever reason, seen 
a recent release.

That said, xinetd has comparatively few lines of code (granted, it's still more 
than tcpserver and tcpsvd for just the configuration file bits alone) when 
placed next to other pieces of software that often run in part with escalated 
privileges like, well, modern full-featured HTTP servers.

Also, it's folly to discount everything above a certain age as insecure. 
tcpserver, part of Dan Bernstein's ucspi-tcp package, has a solid design that 
lends itself very well to running TCP servers that are invulnerable to the 
exploits you're afraid of. I don't think it has seen an update in 15 years.

Anyway, that's all I have to say about that. —n
___
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] remote check in

[Shal Farley]

Scott,

The problem I am having is how to add files, do check-ins and such via 
the UI, mostly regarding doing it remotely without command line access.


I'm far from an expert user of fossil, but I believe the normal setup is 
to have a local copy of the repository, where command line access is 
simple and direct, and use fossil's sync feature to deliver checkins to 
remote servers.


In a multi-developer situation each developer would work with their own 
local repositories, in sync with a common server.


Shal

--
Shal Farley
Cheshire Engineering Corporation
http://www.CheshireEng.com


___
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] remote check in

[Shal Farley]

K,

It would be helpful to the other members of this list if you would not 
chime in with provocative non-sequiturs when you don't know the answer.


Just my humble opinion.

Shal
(see, you trolled me out of my lurking state)

--

Shal Farley
Cheshire Engineering Corporation
http://www.CheshireEng.com


On 10/22/2016 3:52 PM, K. Fossil user wrote:

Hi,

1/ People don't really use Fossil : they do use git/mercurial/etc.
2/ Those who use Fossil use command line most of them.
...
___
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] remote check in

[K. Fossil user]

Hi,

>« So do people who have a check-in or a new file email
the file to the administrator and they add/check-in, or do those
people have command line access? »

1/ People don't really use Fossil : they do use git/mercurial/etc.
2/ Those who use Fossil use command line most of them.
3/ The purpose of SSH (long talk with the Fossil users) is to help people use 
secure remote command line...
(This is how I understand it)
4/ I was wondering if Fossil have got something that is not "command line". I 
dunno.


Best Regards

K.



  De : Scott Doctor 
 À : Fossil SCM user's discussion  
 Envoyé le : Samedi 22 octobre 2016 22h40
 Objet : [fossil-users] remote check in
   
I am trying to figure out how to use fossil for an upcoming 
project. I keep coming back to fossil as the alternatives (git, 
mercurial,...) are just... well I will go bald trying to figure 
them out. I made a test repository to play with and mostly 
figured out the command line commands. The problem I am having 
is how to add files, do check-ins and such via the UI, mostly 
regarding doing it remotely without command line access.

My question is, for example the sqlite fossil system, someone 
wants to check-in a change of a file, or add a new file. How do 
they do such over the internet without having command line 
access? I do not see any operations from the UI that does that. 
Seems adding files, doing check-ins, merges, should all be part 
of the UI. So do people who have a check-in or a new file email 
the file to the administrator and they add/check-in, or do those 
people have command line access?

-- 

-
Scott Doctor
sc...@scottdoctor.com
-

___
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] remote check in

[Scott Doctor]

I am trying to figure out how to use fossil for an upcoming 
project. I keep coming back to fossil as the alternatives (git, 
mercurial,...) are just... well I will go bald trying to figure 
them out. I made a test repository to play with and mostly 
figured out the command line commands. The problem I am having 
is how to add files, do check-ins and such via the UI, mostly 
regarding doing it remotely without command line access.


My question is, for example the sqlite fossil system, someone 
wants to check-in a change of a file, or add a new file. How do 
they do such over the internet without having command line 
access? I do not see any operations from the UI that does that. 
Seems adding files, doing check-ins, merges, should all be part 
of the UI. So do people who have a check-in or a new file email 
the file to the administrator and they add/check-in, or do those 
people have command line access?


--

-
Scott Doctor
sc...@scottdoctor.com
-

___
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] features I'd like to have in fossil

[Richard Hipp]

On 10/22/16, Nikita Borodikhin  wrote:
>
> What I expected from this post is, well, to share my problems with the
> community.  There was a chance I could get a discussion on the problems
> to better understand what people think and whether they find it
> important or not.  That could help me to set the right priority to my work.

And your input is greatly appreciated.  Thank you for contributing.
I'm sure your ideas will have at least some influence on future
directions.

-- 
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] features I'd like to have in fossil

[K. Fossil user]

Hi,

>« This is "fossil-users" mailing list, and it exists to share opinions,
problems, issues, suggestions and so on, would you agree to that? »

Exactly my tought.

>« learning curve »

I've said something about that.

>« The less people use it
- the less new ideas, less improvements and evolution »

Unfortunately you are right.

>« I do not propose any breaking changes »

Not me either.

>« What I expected from this post is, well, to share my problems with the
community. There was a chance I could get a discussion on the problems
to better understand what people think and whether they find it
important or not. That could help me to set the right priority to my work. »

Agreed !
I may add that I am here to help Fossil : this does _not_ mean that I would let 
people say something wrong about me or what I've said or think.

Again, Fossil needs to do/improve marketing.



Best Regards

K.


  De : Nikita Borodikhin 

*snip*
Hi Richie,
*snip*
   ___
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] features I'd like to have in fossil

[Nikita Borodikhin]

Hi Richie,


On 10/22/2016 06:40 AM, Richie Adler wrote:



* suggestions on what could be improved to make Fossil easier to use for me

As a mere reader of the list, I have to ask: why should *the Fossil team*
consider this important?

You haven't presented any compelling reason to change significatively the way
Fossil operates, besides that it would be nice for you.

Am I missing something?


This is "fossil-users" mailing list, and it exists to share opinions, 
problems, issues, suggestions and so on, would you agree to that?



Well, I shared some my problems and I proposed solutions I saw in other 
projects for those problems.  I am far from assuming that I am 
exceptional, so I have to assume that there are other people who have 
the same problems and who would benefit from the changes.  Some of the 
issues are caused by differences between fossil and other systems, big 
enough to make learning curve too steep for my taste.  The steeper the 
curve - the less new people would adopt fossil.  The less people use it 
- the less new ideas, less improvements and evolution.



By the way, I do not propose any breaking changes.  I propose adding new 
concepts and commands and improve the way existing ones work, but those 
are all non-critical changes.  The only thing that needs careful 
consideration is "combined databases", but it also could be implemented 
without losing compatibility.



I do not expect anyone working on a free project to do anything for me.  
I do not even expect any review or criticism, for that matter.  No work 
to share - no feedback, right?  I would want to have my problems solved 
though, and I am going to work and implement my proposals myself and 
_then_ get review from people. If then people say "no way, we do not 
need this in Fossil" - that's fine, that's how open project works.  I'll 
keep my changes in my local repository.



What I expected from this post is, well, to share my problems with the 
community.  There was a chance I could get a discussion on the problems 
to better understand what people think and whether they find it 
important or not.  That could help me to set the right priority to my work.



Nikita



___
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] Why we should NEVER use inetd/xinetd

[K. Fossil user]

Hi,

I was wondering if it is necessary to create a new thread just for 
inetd/xinetd...
Two guys said this :
>« Wait, what's wrong with inetd? »
and, this :
>« That ellipsis really should be filled in with more details. Would you 
>perhaps be willing to elaborate a bit on what you mean? »

These are simple questions from people who would like to understand, nothing 
else of course.At least, understand that they are NOT trolls.

1/ As I've stated in the past according to people I do know, for security 
reason, inetd/xinetd is not recommended.I was explained to never use ONE daemon 
for many servers. When needed ONE daemon for ONE server and not more.
At least if you must use inetd, use xinetd.

2/ Xinetd is old (four years ?) so may be not secure.

3/ And this info should definitely helps :
rc or inetd? What should I use? | The FreeBSD Forums
« Modern FreeBSD installations run separate daemons for almost every service 
nowadays, and inetd is all but deprecated. It's probably only around for 
historical/compatibility reasons. Starting services from /etc/rc.conf is the 
modern FreeBSD way. »


P.S. : I will never understand why people don't know about security issue when 
it comes to inetd.

Best Regards

K.
___
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] Can fossil bind to a single address?

[Andy Bradford]

Thus said "Andy Bradford" on 22 Oct 2016 13:34:42 -0600:

> Do we want to address the bugs that Venkat Iyer recently reported with
> the ticket command before or after 1.36?

I believe at least the transaction bug is addressed by:

http://www.fossil-scm.org/index.html/info/1b6635a47fd8a1ad

Now that we don't break the database, can we defer the other issue after
1.36?

Thanks,

Andy
-- 
TAI64 timestamp: 4000580bc466


___
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] Can fossil bind to a single address?

[Andy Bradford]

Thus said Richard Hipp on Sat, 22 Oct 2016 13:04:52 -0400:

> I think it is reasonable to request a new option to 'fossil server" to
> bind to a single address (other than loopback).

Definitely, given that  ``fossil server'' exists, one  shouldn't have to
rely on tcpserver  or any other inetd-like setup to  bind to a different
address.

> So are there any objections now to taking trunk as the 1.36 release so
> that we can move forward on these kinds of things?

Do we want  to address the bugs that Venkat  Iyer recently reported with
the ticket command before or after 1.36?

If after, then I think we're ready to go with 1.36.

Andy
-- 
TAI64 timestamp: 4000580bbf76


___
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] Broke repository using command line.

[Andy Bradford]

Thus said Venkat Iyer on Fri, 21 Oct 2016 21:39:11 -0700:

> The  icomment stuff  must have  recently changed.  "User Comments"  is
> different than  "comments". I used  to do  +comments and that  used to
> append to the end of the ticket before. But if I do that now, it shows
> up  *before*  the  user  comments  entered  from  the  web,  which  is
> confusing.

I don't know as  much about the ticketing system so I  don't know how it
used  to work,  but  perhaps someone  who  uses it  can  comment on  the
difference between comment/icomment and what they mean.

> So based on  someone's advice on the  tcl chat I did  icomments. But I
> mistakenly added a + though apparently I shouldn't have.

I was  the one who  suggested using  icomment because that  ``worked for
me'' but perhaps it was the wrong  thing to begin with. Maybe the bug is
that +comment  doesn't do what it  used to do and  icomment shouldn't be
used, or its use is different than expected.

Apologies for misleading you and getting your repo in a bad state. :-)

Thanks,

Andy
-- 
TAI64 timestamp: 4000580bbeab


___
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] Broke repository using command line.

[Andy Bradford]

Thus said Venkat Iyer on Fri, 21 Oct 2016 21:22:13 -0700:

> I tried  to find  where that  +icomment was  coming from  without much
> success. Any advice appreciated. Fossil sqlite3 hackery is fine.

fossil ticket ls fields

shows icomment in my database.

It  looks like  there  should  have been  a  transaction wrapped  around
whatever ``fossil ticket set'' does because when I tried your command it
actually returned an  SQL error, but then apparently  also committed the
changes, in spite of the error:

$ fossil ticket change 0f3bfc6c55 +icomment "ivenkat added on 
> 2016-10-21.18:50:20 PDT:
> script checked in to [1a8ae0e34f]"
SQLITE_ERROR: table ticketchng has no column named +icomment
fossil: table ticketchng has no column named +icomment
INSERT INTO 
ticketchng(tkt_id,tkt_mtime,"+icomment",tkt_rid)VALUES(1,:mtime,'ivenkat added 
on
2016-10-21.18:50:20 PDT:
script checked in to [1a8ae0e34f]',3)

So  now I've  got something  in my  database that  is causing  problems 
because it  looks like  there was  something partially  committed. This 
failed  because  +icomment  apparently   was  not  interpreted  as  the 
documentation indicates it should be:   

If you use +FIELD, the VALUE is appended to the field FIELD.

Seems like a bug.  It also seems like a bug  that the transaction wasn't
rolled back on the initial attempt to insert the data. So two bugs.


> I tried  to find  where that  +icomment was  coming from  without much
> success. Any advice appreciated. Fossil sqlite3 hackery is fine.

I'm not sure this will work, but I think it should be possible to delete
the bad artifact from the blob  table. You'll have to identify which one
it is. You could use ``fossil  deconstruct'' and then find the file that
has a ``J +icomment'' card in it. Or you could use something like:

$ fossil test-describe-artifacts
  d87cb4d455c100a2 unknown
  ec6692e5d6e071e5 check-in on 2016-10-22 18:53
  ad17035460356de4 ticket 51bf48d3fd8eaf226756b
  8adb146462e68585 ticket 51bf48d3fd8eaf226756b
  86d1022b4d5d6b7f ticket 51bf48d3fd8eaf226756b
  8a3bd4261e6175f0 ticket 51bf48d3fd8eaf226756b

Notice  that the  first artifact  in  my list  is unknown,  and it  just
happens to be the bogus record. If you have many such unknown artifacts,
it might be more work this way. At any rate, then delete it:

$ fossil art d87cb4d455c100a2
D 2016-10-22T18:57:16.614
J +icomment funziona\snumero\sdue
K 51bf48d3fd8eaf226756ba0037a8fed7ac5c165c
U amb
Z 2e583adf82bab42b0648188b78fb

$ fossil info d87cb4d455c100a2
uuid: d87cb4d455c100a208a298c98f8ae06d2235d1f7

printf "DELETE FROM blob WHERE uuid = 
'd87cb4d455c100a208a298c98f8ae06d2235d1f7';" | fossil sql

And now it rebuilds:

$ fossil rebuild
  100.0% complete...

I think the most important bug fix is to ensure that the ticket changes 
are wrapped  in a transaction  to avoid  this happening in  the future. 
Then figuring out what's wrong with +icomment.  

Andy
-- 
TAI64 timestamp: 4000580bbd40


___
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] Can fossil bind to a single address?

[Richard Hipp]

I think it is reasonable to request a new option to 'fossil server" to
bind to a single address (other than loopback).

But I'm unwilling to make that change until the next release cycle.

So are there any objections now to taking trunk as the 1.36 release so
that we can move forward on these kinds of things?
-- 
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] Can fossil bind to a single address?

[Andy Bradford]

Thus said "K. Fossil user" on Fri, 21 Oct 2016 22:55:56 -:

> However, xinetd or inetd are not recommended...

I usually recommend tcpserver.

Andy
-- 
TAI64 timestamp: 4000580b97d7


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

[fossil-users] typo on the download page

[Svyatoslav Mishyn]

Hi there,

here (https://www.fossil-scm.org/index.html/uv/download.html) are
links like these:
Version 1.35 => https://www.fossil-scm.org/fossil/timeline?c=version-1.35;y=ci
Version 1.34 => https://www.fossil-scm.org/fossil/timeline?c=version-1.34;y=ci
...

there should be '&' instead of ';'
(i.e. https://www.fossil-scm.org/fossil/timeline?c=version-1.35=ci)


-- 
I am not a native English speaker,
so feel free to correct any spelling or grammatical errors!


signature.asc
Description: PGP signature
___
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] features I'd like to have in fossil

[Richie Adler]

> * suggestions on what could be improved to make Fossil easier to use for me

As a mere reader of the list, I have to ask: why should *the Fossil team*
consider this important?

You haven't presented any compelling reason to change significatively the way
Fossil operates, besides that it would be nice for you.

Am I missing something?

___
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] features I'd like to have in fossil

[K. Fossil user]

Hi,
I don't have much time now but I just answer to what you've said :
No I don't ask Fossil team to switch now over MatterMost.I ask them to think 
about it. I remind you that I am not the owner of the Fossil.
It is not because I ask it for the Best of Fossil that it would mean that I do 
want that myself.

And for the record, I don't want to use Mattermost with Fossil as an 
IM/Chat/communication-thing-you-may-think.E-mail suffice.  
Best Regards

K.

  De : Warren Young 
 À : Fossil SCM user's discussion  
 Envoyé le : Samedi 22 octobre 2016 3h08
 Objet : Re: [fossil-users] features I'd like to have in fossil
   
Yes, and the impression I got is that the thing you are most concerned with is 
switching the community over to MatterMost.

Personally, the exact method the community communicates is one of the least 
important parts of Fossil.  I’d far rather time and effort be spent on Fossil 
itself rather than on chasing the IM/chat/email alternative of the month.
___
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] features I'd like to have in fossil

[Nikita Borodikhin]

Color support should be customizable and should have global off switch.

Not only color blindness is the issue, but also people have all sort of 
background colors on their terminals.  Around me, I see black, gray, 
white, green and blue backgrounds.



On 10/22/2016 12:35 AM, Scott Robison wrote:


> If you color lines by meaing, it is easier to understand:

Unless you're color blind, in which case it might be impossible to 
understand.




___
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] features I'd like to have in fossil

[Scott Robison]

> If you color lines by meaing, it is easier to understand:

Unless you're color blind, in which case it might be impossible to
understand.
___
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] features I'd like to have in fossil

[Nikita Borodikhin]

Hi Warren,


On 10/21/2016 11:14 AM, Warren Young wrote:

On Oct 21, 2016, at 10:02 AM, Nikita Borodikhin  wrote:

== color support - review the change, history analysis ==

One should not underestimate the significance of color on terminals these days, 
that's why both git and mercurial and a lot of tools have color support in 
their base distribution.  It makes it much easier to spot the changes in a diff

For diff, simply install colordiff, which is almost certainly already packaged 
for your OS.  Then:

 $ fossil set diff-command 'coloridff -wu'
 $ fossil diff -r 2016-10-01 | less


to group similar files together in a status report at a glance

Define “similar.”  Do you just mean that all the modified files should group 
together separate from the added files and such, or something different?

This is one of the areas where working code will speak louder than well-crafted 
prose.

Let's suppose I have some changes to fossil:

$ fossil status
EDITED src/bisect.c
MISSINGsrc/blob.c
EDITED src/comformat.c
ADDED  src/configuration.c
MISSINGsrc/configure.c
EDITED src/content.c



If you color lines by meaing, it is easier to understand:


$ fossil status
EDITED src/bisect.c
*MISSINGsrc/blob.c*
EDITED src/comformat.c
ADDED  src/configuration.c
MISSINGsrc/configure.c
EDITED src/content.c





== change sets - preparing the change ==

I often end up having several sets of unrelated changes.

You admitted to not using branches, apparently because you don’t see the point 
of them in a single-developer project.  This is one good use for them.

That is, if you’re working on one feature and then see that you’ve gone off on 
a  tangent and are now building something unrelated, you can check the first 
feature’s unfinished changes into a branch, then return to the trunk to work on 
the second feature.

You’re using branches in this case to stash unfinished work without breaking 
the trunk or admixing unrelated features in a single checkin.
I can use branches for that, that's true.  There is also another use 
case - changes are not directly related to each other and are logically 
separated, but I have to have both of them until I finish the work.  
E.g. Makefile changes to dramatically speed up the build on my machine.





Working with git, I use staging area to collect the needed changes and group 
them together

I think the git staging area fights against team cohesiveness, primarily 
serving the needs of the sort of developer who likes to go off and hide in 
their office, not showing their work to their team members until it’s 
“perfect.”  Committing publicly, early, and often is objectively better, a fact 
that falls naturally out of the mathematics of control theory.

I realize that this is not a problem for you, but I’d guess that more Fossil 
users are on teams than not.
Anyway, before the commit, you have to make sure you're committing what 
you want, and you review your changes before the commit, right?  Staging 
area in git is the instrument created exactly for what I'm taking about 
- to help developer to prepare the commit and separate what he's going 
to commit from what he's not going to commit.


How much time it takes - minutes, hours, or weeks - is up to developer.  
Every instrument can be perused, you can hit nails with a microscope, 
but it is not intended to be used that way.





subversion really shines here with its changelists

Some months ago, a proposal was made that I consider vastly superior to svn 
change lists: a flag for the stash command that would let you select and reject 
each hunk of the current diff interactively.

If you had three essentially unrelated changes in the current working copy, you 
could stash all the hunks belonging to two of them, then test the third change 
separately and check it in once you’re happy.  Then you could “stash pop” and 
repeat to polish the other two, one at a time.

It is important that this not be implemented in terms of checkin, since you 
need to test each unrelated feature separately before checking it in.


I missed that proposal, but it must looks more like hg record than svn 
changelists.  If that is the case, it is more granular, but in the way 
it becomes a completely different tool.  It just works on too a 
different level.





== grep - development support ==

Often the projects building process leaves many temporary files in the working 
directory.  I could grep over the directory using standard grep but then I have 
to filter out those temporary files created by my build system.

The solution to that is ag, The Silver Searcher:

   http://geoff.greer.fm/ag/

If you’re looking for a project, it would be nice if someone would teach ag 
about Fossil ignore rules.  It already knows about git, hg, and svn.  
Meanwhile, we have its built-in .agignore feature.

ag is awesome in many other ways.  In addition to being much faster than grep 
and with a shorter typical