Re: [fossil-users] Is this a crazy idea?

[Reimer Behrends]

Abilio Marques wrote:

Cool things about
that... yes, you can select what to include (seems that line by line).


This does not require a staging area. Darcs, for example, had such 
selective commits since its inception (in fact, it was and is the 
default mode of operation for Darcs, for better or worse).


Reimer Behrends
___
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] Is this a crazy idea?

[Reimer Behrends]

die.drachen wrote:
> The git staging area is useful to my workflow because I am often
> making changes and testing something, but later decide to have
> separate commits within all the changes. This helps preserve a nicer
> history where commits usually have single-responsibility. For example,
> fixing a null pointer in a button click handler, but also tweaking the
> button's sizing/border/etc. to be consistent within the UI. I would
> likely make those two changes at once and test locally, but ultimately
> have separate commits for each change. On other occasions where I
> might end up in a similar situations is when finding out one bug is
> actually multiple bugs.

There are three points I'd like to make here:

First, the safer (and arguably overall better) approach is to recognize 
that stash/shelve operations are the inverse of the staging area for 
this purpose. I.e., rather than stage a partial commit, you stash 
everything but the partial commit, then commit whatever changes remain 
in toto. This does not require the staging area and ensures that, e.g., 
you're not committing something that doesn't even compile (which breaks 
bisect, CI tools, etc.).


Second, even if you prefer not to do it this way, "git commit --amend" 
essentially made the staging area superfluous a long time ago for the 
purpose of splitting commits.


Third, while splitting commits (where you accidentally mashed multiple 
things together that you later realize should be separated) is a very 
relevant feature, this is largely a problem of the user interface, not 
the staging area. The staging area is frequently used because many 
graphical Git clients provide excellent UI tooling for staging parts of 
a file as a commit. However, this does not require a staging area; see, 
e.g., Bazaar's "qshelve" command for a graphical tool that provides a 
similar feature for stashing partial commits.


> It sounds like fossil is similar to mercurial - mercurial's commit
> command by default includes all local changes, but arguments can be
> specified for including/excluding files (or file patterns).

Keep in mind that Mercurial also has Mercurial queues, which is (for 
better or worse) a staging area on steroids. Also, what I said about 
"git commit --amend" above applies equally to "hg commit --amend".


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

[fossil-users] Convenient command for standardizing and simplifying marking a commit as a mistake.

[Henry Adisumarto]

Hi,

I wonder why there isn't a command for simplifying the process of marking a
commit as a mistake. So with a single command, fossil will:

*Move the commit and its derived commits to mistake branch.

*If there is a leaf in the branch, the leaf will be closed.

*The mistaken commits will be hidden from the timeline.

*If any of the mistaken commits have been merged into another
branch, the mistaken commits will be backed out from the valid branches.

*. (Perhaps some other stuffs I may not have thought about at the
moment.)

 

Let me know what you guys think about it.

 

Thanks.

 

Henry



smime.p7s
Description: S/MIME cryptographic 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] multiple independent check-outs against the same repository

[Richard Hipp]

On 3/19/15, Abilio Marques  wrote:
>
> PS: after running my quick test in fossil 1.31, I ended with two separate
> artifacts, both on trunk, but without a common ancestor. I'm running
> Ubuntu, and I haven't compiled the 1.32. I believe that version was
> released as a patch for this common ancestor issue. Will my test behave
> differently on 1.32?
>

Yes, that is yet another failing of the ill-conceived patch that
allows "fossil init" to create a repository without an initial
check-in.  I rue the day that I allowed that patch to land on trunk.
But it is all fixed now - you won't have the problem with 1.32.

-- 
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] multiple independent check-outs against the same repository

[Abilio Marques]

I imagined some of those scenarios right away after my experiment... Some
are great... Until today, I was doing a fossil clone file://  or ssh:// ...
Now I can deal with just a single copy of the repo.

I only see it quickly and indirectly mentioned in section 2.3 here:
http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki

But the text in there doesn't tease me to try new things not available in
other VCS. Plus, is kinda hidden, so it ain't obvious you can do it that
way. Is it possible to do describe it somewhere for future reference?


PS: after running my quick test in fossil 1.31, I ended with two separate
artifacts, both on trunk, but without a common ancestor. I'm running
Ubuntu, and I haven't compiled the 1.32. I believe that version was
released as a patch for this common ancestor issue. Will my test behave
differently on 1.32?

On Thu, Mar 19, 2015 at 10:57 PM, Richard Hipp  wrote:

> On 3/19/15, Abilio Marques  wrote:
> > After reading Mr. Hipp answer to some previous email about git saying:
> >
> > So the staging area is being used as a way of working around the fact
> > that Git does not allow multiple independent check-outs against the
> > same repository?  Am I understanding that correctly?
> >
> > I started to think: what does it mean to have "multiple independent
> > check-outs"? And I knew I wouldn't be able to sleep well because of not
> > knowing. So I created a new test repo, and began:
> >
> > mkdir test
> > cd test
> > fossil new test.fossil
> > mkdir a b
> > cd a
> > fossil open ../test.fossil
> > echo "file a" > a.txt
> > cd ..
> > cd b
> > fossil open ../test.fossil
> > echo "file b" > b.txt
> > cd ..
> > fossil status # replied not within an open checkout
> >
> > Then went to commit in each subdirectory... then did a status... both
> > reflected the check-ins in the correct order... and the other directories
> > weren't there. Actually going to a (the first commited one) and running
> > fossil update trunk did:
> >
> > ADD b.txt
> > REMOVE a.txt
> >
> > So far seems magic, as I don't seem to grasp the power, uses and
> > implications for it. Is there any documentation? This is my first
> approach
> > to what Mr. Hipp said. Am I mistaken?
> >
>
> You are doing it right.
>
> There is no documentation because I could not conceive of wanting to
> use a VCS in any other way.
>
> Scenario:  You want to compare the performance of two different
> versions of the project.  So you do two simultaneous checkouts, in
> separate directories, and run speed tests on each.
>
> Scenario:  You in the middle of a big change when a support request
> from a customer comes in that requires you to work on a release from a
> year ago.  No need to "stash" all the changes you are in the middle
> of, just open the older version in a separate directory - make changes
> there and branch it if necessary, then go back to what you were doing.
>
> Scenario:  Do simultaneous builds with different compile-time options
> for the same version of the code in three separate directories.
>
> Scenario:  Work on four separate branches, all at the same time,
> located in four separate directories.
>
> Scenario:  Be editing code in a branch while simultaneously running a
> bisect is on trunk.
>
> And so forth
>
> --
> 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] multiple independent check-outs against the same repository

[Richard Hipp]

On 3/19/15, Abilio Marques  wrote:
> After reading Mr. Hipp answer to some previous email about git saying:
>
> So the staging area is being used as a way of working around the fact
> that Git does not allow multiple independent check-outs against the
> same repository?  Am I understanding that correctly?
>
> I started to think: what does it mean to have "multiple independent
> check-outs"? And I knew I wouldn't be able to sleep well because of not
> knowing. So I created a new test repo, and began:
>
> mkdir test
> cd test
> fossil new test.fossil
> mkdir a b
> cd a
> fossil open ../test.fossil
> echo "file a" > a.txt
> cd ..
> cd b
> fossil open ../test.fossil
> echo "file b" > b.txt
> cd ..
> fossil status # replied not within an open checkout
>
> Then went to commit in each subdirectory... then did a status... both
> reflected the check-ins in the correct order... and the other directories
> weren't there. Actually going to a (the first commited one) and running
> fossil update trunk did:
>
> ADD b.txt
> REMOVE a.txt
>
> So far seems magic, as I don't seem to grasp the power, uses and
> implications for it. Is there any documentation? This is my first approach
> to what Mr. Hipp said. Am I mistaken?
>

You are doing it right.

There is no documentation because I could not conceive of wanting to
use a VCS in any other way.

Scenario:  You want to compare the performance of two different
versions of the project.  So you do two simultaneous checkouts, in
separate directories, and run speed tests on each.

Scenario:  You in the middle of a big change when a support request
from a customer comes in that requires you to work on a release from a
year ago.  No need to "stash" all the changes you are in the middle
of, just open the older version in a separate directory - make changes
there and branch it if necessary, then go back to what you were doing.

Scenario:  Do simultaneous builds with different compile-time options
for the same version of the code in three separate directories.

Scenario:  Work on four separate branches, all at the same time,
located in four separate directories.

Scenario:  Be editing code in a branch while simultaneously running a
bisect is on trunk.

And so forth

-- 
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] Is this a crazy idea?

[Andy Bradford]

Thus said Abilio Marques on Thu, 19 Mar 2015 22:10:41 -0430:

> git  commit -a  or git  commit filename,  you're skipping  the staging
> area.

Yes, that's right---thanks to your  explanation. I haven't needed it and
now that  I understand it (at  least according what has  been discussed)
I'm certain I don't need it. :-)

> I suggest you  (if you haven't done  it) to avoid using  git commit -a
> and avoid using git commit filenames.

Why?

Based on what I've seen so far, it doesn't really benefit me (and I fail
to see how my use of it will benefit others).

Thanks,

Andy
-- 
TAI64 timestamp: 4000550b909e


___
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] Is this a crazy idea?

[Andreas Kupries]

On Thu, Mar 19, 2015 at 6:10 PM, Abilio Marques  wrote:
> Really? didn't know that... I'm impressed by that. There've been times when
> I've needed it, then proceeded to stash, then stash apply, then modified,
> then committed, then stash popped and so on...
>
> Unless you mean that you do a git add, the modify the same file, and commit
> as is, without doing git add again... that way you can selectively commit a
> sub-set, but depends on the moment you did the adds. Never heard of
> selectivity.
>
> I know it could be off topic (does it?), but how would you do that? Do you
> have an example?

I actually do not know how to do it from the command line.

What I use is the "git gui" command (*), which is a light Tk interface
to essentially look at the workspace and the staging area, with a list
of files to the left, modified, new, deleted, and for modified files I
see the unified diff of my changes for the selected file.

I use that to go through all the changes, review them, and choose
which to place into the commit, whole file, chunks, parts of a chunk
(stage file, stage chunk, stage lines). How it does all this
underneath, i.e. which other git commands get used and how, that I do
not know.



(*) Note, "git gui" is not "gitk", although each can invoke the other,
as a separate process.

>
> On Thu, Mar 19, 2015 at 8:28 PM, Andreas Kupries 
> wrote:
>>
>> On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp  wrote:
>> > On 3/19/15, Abilio Marques  wrote:
>> >>
>> >>  Most of the friends I've shown fossil to love the idea of having SCM,
>> >> wiki
>> >> and tickets in the same, tiny place. Looks promising for them... but
>> >> then
>> >> they miss the git staging area.
>> >>
>> >
>> > Fossil does give you the ability to do a partial commit  (in case you
>> > are really want to commit changes that you have not tested).  Just
>> > list the subset of files you want to commit on the commit
>> > command-line:
>> >
>> >   fossil commit one.txt two.txt dir-three/
>> >
>> > If you include directories in the list, then all modified files
>> > underneath those directories are committed.
>> >
>> > Does the git staging area provide any capability beyond this?
>>
>>
>> AFAIK with git staging you can select specific changes in a single
>> file as well, to commit only a sub-set of changes in that file.
>>
>>
>> --
>> Andreas Kupries
>> Senior Tcl Developer
>> Code to Cloud: Smarter, Safer, Faster™
>> F: 778.786.1133
>> andre...@activestate.com, http://www.activestate.com
>> Learn about Stackato for Private PaaS: http://www.activestate.com/stackato
>> ___
>> 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
>



-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
F: 778.786.1133
andre...@activestate.com, http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] multiple independent check-outs against the same repository

[Abilio Marques]

After reading Mr. Hipp answer to some previous email about git saying:

So the staging area is being used as a way of working around the fact
that Git does not allow multiple independent check-outs against the
same repository?  Am I understanding that correctly?

I started to think: what does it mean to have "multiple independent
check-outs"? And I knew I wouldn't be able to sleep well because of not
knowing. So I created a new test repo, and began:

mkdir test
cd test
fossil new test.fossil
mkdir a b
cd a
fossil open ../test.fossil
echo "file a" > a.txt
cd ..
cd b
fossil open ../test.fossil
echo "file b" > b.txt
cd ..
fossil status # replied not within an open checkout

Then went to commit in each subdirectory... then did a status... both
reflected the check-ins in the correct order... and the other directories
weren't there. Actually going to a (the first commited one) and running
fossil update trunk did:

ADD b.txt
REMOVE a.txt


So far seems magic, as I don't seem to grasp the power, uses and
implications for it. Is there any documentation? This is my first approach
to what Mr. Hipp said. Am I mistaken?
___
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] Is this a crazy idea?

[Abilio Marques]

I think I missed you here, or you missed me, but I know you got the fact
that by doing:
git commit -a or git commit filename, you're skipping the staging area.

For example, by doing git commit -a -m "this is a test", what git is
internally doing is the equivalent to:
git add -A
git commit -m "this is a test"

And by doing git commit -m "this is a test" filenames, it's doing:
git add filenames
git commit -m "this is a test"

I suggest you (if you haven't done it) to avoid using git commit - and
avoid using git commit filenames . The way you're working, well... that was
the way I did it the first days I used git, until a close friend of mine
told me to drop it and work like everybody else.

I said no, 3 minutes later I was trying... had to learn that the ADD
command was for something else that adding a new file (linus tovards, why?
just use the word STAGE). Believe me, reading about staging area seemed
weird and hard to grasp... why would I complicate with those things? In the
end I learned how to use it, and it improved communication with my team.
That's the reason why I tell you to give it a shot.

On Thu, Mar 19, 2015 at 9:53 PM, Andy Bradford 
wrote:

> Thus said Abilio Marques on Thu, 19 Mar 2015 21:25:05 -0430:
>
> > By doing git commit -a, your doing an implicit
> >
> > git  add  -A before  the  commit,  which  stages all  the  uncommitted
> > changes, and then you're working close to what you would in fossil.
>
> I see, this is totally foreign to how I use git. I have never had to use
> ``git add  -A'', nor have I  had to do  ``git add'' for files  that were
> modified, only files that do not exist in the current checkout.
>
> > You do some changes, then you select the files (not it seems that even
> > line by line changes are selectable) you want to include in the commit
> > by doing "git add", and then you commit.
>
> Again, this is foreign  to me. I'm not sure I see the  benefit to such a
> feature. I  can select which  files (though not  which lines) when  I do
> ``fossil  commit .''  Having a  step  in between  the commit  and
> modifying the  files just  seems just  more state that  I have  to worry
> about.
>
> > git status # You'll see it talks about unstaged changes by this point
>
> Oh, yes, I do use ``git status'' similar to how I use ``fossil status''
>
> > git commit -m "another line in the test" # I believe it will refuse
>
> Yes, it will  refuse. Normally, I just  use git commit -a  or git commit
> filename. So I think I can safely say that, no, I do not use the staging
> area, at least not the way Linus intended it.
>
> I think this is a non-feature.
>
> Thank you for taking  the time to explain to me what  I'm missing out on
> by using ``git commit -a'' and ``git commit '' :-)
>
> Andy
> --
> TAI64 timestamp: 4000550b84b7
>
>
>
___
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] Is this a crazy idea?

[Andy Bradford]

Thus said Abilio Marques on Thu, 19 Mar 2015 21:25:05 -0430:

> By doing git commit -a, your doing an implicit
>
> git  add  -A before  the  commit,  which  stages all  the  uncommitted
> changes, and then you're working close to what you would in fossil.

I see, this is totally foreign to how I use git. I have never had to use
``git add  -A'', nor have I  had to do  ``git add'' for files  that were
modified, only files that do not exist in the current checkout.

> You do some changes, then you select the files (not it seems that even
> line by line changes are selectable) you want to include in the commit
> by doing "git add", and then you commit.

Again, this is foreign  to me. I'm not sure I see the  benefit to such a
feature. I  can select which  files (though not  which lines) when  I do
``fossil  commit .''  Having a  step  in between  the commit  and
modifying the  files just  seems just  more state that  I have  to worry
about.

> git status # You'll see it talks about unstaged changes by this point

Oh, yes, I do use ``git status'' similar to how I use ``fossil status''

> git commit -m "another line in the test" # I believe it will refuse

Yes, it will  refuse. Normally, I just  use git commit -a  or git commit
filename. So I think I can safely say that, no, I do not use the staging
area, at least not the way Linus intended it.

I think this is a non-feature.

Thank you for taking  the time to explain to me what  I'm missing out on
by using ``git commit -a'' and ``git commit '' :-)

Andy
-- 
TAI64 timestamp: 4000550b84b7


___
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] Is this a crazy idea?

[Andy Bradford]

Thus said Abilio Marques on Thu, 19 Mar 2015 21:29:28 -0430:

> As  a side  note, one  of the  reasons I  dislike git  is because  the
> commands don't do (do as in never) what their name imply, and some are
> hidden  as  subcommands  inside  commands that  are  meant  for  other
> purposes.

You mean  like overloading ``git  add'' to be  both ``git add''  for new
files to  be added to the  checkout (and eventually the  repository) and
using ``git add'' to really mean ``git stage''?

Andy
-- 
TAI64 timestamp: 4000550b8522


___
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] Is this a crazy idea?

[Warren Young]

On Mar 19, 2015, at 5:52 PM, Abilio Marques  wrote:
> 
> I've toyed with the idea of writing a "shim" so fossil can be used in place 
> of git or subversion.

I speak only pidgin Git, so I wouldn’t like to speculate about how difficult 
such a shim would be to write.

I can, however, speak to the svn case.  I have used Subversion heavily for 
about a dozen years now, so I can pretty confidently predict that you’re going 
to run into a bunch of areas where the semantics of Fossil and Subversion 
differ enough to make building such a shim tricky, and in places actually 
difficult.

Here are the differences that immediately occur to me:

1. svn uses a monotonically-increasing revision number for the whole repository 
as the unique identifier for each checkin.  Fossil uses cryptographic hashes 
instead.  This affects every command in both systems that take an -r flag, and 
more.

(“More” because Fossil doesn’t always use -r to specify a checkin.  Fossil is 
somewhat of a bicameral mind on this point: sometimes you use -r, and other 
times you just give it as a bare parameter.)

For the same reason, I don’t know how you’d implement an svnversion wrapper in 
terms of Fossil.


2. Fossil branching and tagging are baked into the database schema; there’s 
only one way to do it.

In Subversion, branching and tagging are a mere *convention* built on top of 
the svn copy command, and there is no requirement that your copy target be 
somewhere under the repo’s branches or tags directories; that too is just a 
convention.

I don’t think you can actually emulate the full scope of the svn copy command 
in terms of Fossil.  There are things you can do with that command that do not 
map neatly to fossil tag and branch commands.


3. fossil timeline is not quite the same thing as svn log.

First you have to decide if you want to translate the output formats so that 
it’s parseable by tools that know how to read svn log output.

Then you have a deeper problem, which is that the two commands simply don’t 
entirely overlap in their capability.

Some svn log commands will be straightforward to translate into fossil timeline 
commands:

svn log -r{2014-12-25}:HEAD

is the same as:

   fossil timeline after 2014-12-25 -n 0

But, svn also lets me give an arbitrary log endpoint, which fossil timeline 
doesn’t:

svn log -r{2014-12-25}:r1234

How will your shim cope?


4. svn does one-step mv and rm operations.  Fossil currently requires a 
separate OS-level mv or rm to accompany the Fossil command in order to make the 
file tree consistent with the repo.

I’ve advocated for this to change, though it’s looking like if something along 
this line does happen, it won’t be to make Fossil behave exactly like svn, but 
perhaps more like Monotone instead.


5. svn ci is not quite the same thing as fossil ci.  Perhaps “fossil ci .” is 
close enough for your purposes.  (i.e. Subversion checks in only files in the 
current directory and its children, by default.)


6. svn allows sub-repo checkouts.  Fossil doesn’t.  (Yet.)


7. There is no equivalent to svn [un]lock in Fossil.  (Praise Ritchie!)


8. Emulating svn merge in terms of fossil merge amounts to taking a simple and 
straightforward interface and complexifying it.


9. svn doesn’t even blink if you try to check in a binary file.  Fossil copes 
just fine with binary files, too, but by default it second-guesses you whenever 
you do it with a file that isn’t on its glob whilelist.


10. svn info more or less combines what Fossil implements separately via info 
and finfo.  I think it might be tricky to work out which Fossil command to call 
for a given set of args to your svn wrapper.


11. svn stat and fossil stat are conceptually the same thing, but their output 
formats are quite different.


12. fossil open kind of overlaps the effects of svn co and svn switch, but not 
entirely.


13. Most of the svn prop{get,set,edit,del} properties do not exist in Fossil:

svn:ignore: Fossil has the ignore-glob setting, but it’s very much not the same 
thing.  Fossil and svn are almost inverses in the way they handle file 
ignorance.  (Ignoration?  Ignorification?)

svn:keywords: Fossil doesn’t do RCS/CVS-like keyword substitution at all, on 
purpose.

svn:executable: A similar per-file property exists in Fossil, but it’s more of 
an implicit property.  To make the shim behave *exactly* like svn, you’re going 
to have to defeat Fossil’s implicit use of the file’s modes to implement this 
property.

svn:eol-style: Fossil doesn’t do CRLF translation, ever.  I think those 
interested in using such a shim will be a self-selected set of people who have 
a greater-than-average interest in having such a feature than those willing to 
just switch to Fossil.  You may be asked to emulate this behavior on top of 
Fossil.

svn:mime-type: The “doc” URL handler in Fossil has a hard-coded implementation 
of this, which probably obviates the need to emulate this property, but perhaps 
someone needs the flex

Re: [fossil-users] Is this a crazy idea?

[Abilio Marques]

Yes, I realized you seem to be right and nobody told me (I learnt git on my
own), but in git, you can run git add --interactive (and it allows you to
selectively work with each uncommitted add you did) and there is also git
add --edit, which allows you to directly edit the unified patch in your
favorite text editor (the one that will be stored in the commit).

Seems REALLY powerful, but need to play more with it. As a side note, one
of the reasons I dislike git is because the commands don't do (do as in
never) what their name imply, and some are hidden as subcommands inside
commands that are meant for other purposes. Fossil should keep away from
that road of uncertainty.

On Thu, Mar 19, 2015 at 8:28 PM, Andreas Kupries 
wrote:

> On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp  wrote:
> > On 3/19/15, Abilio Marques  wrote:
> >>
> >>  Most of the friends I've shown fossil to love the idea of having SCM,
> wiki
> >> and tickets in the same, tiny place. Looks promising for them... but
> then
> >> they miss the git staging area.
> >>
> >
> > Fossil does give you the ability to do a partial commit  (in case you
> > are really want to commit changes that you have not tested).  Just
> > list the subset of files you want to commit on the commit
> > command-line:
> >
> >   fossil commit one.txt two.txt dir-three/
> >
> > If you include directories in the list, then all modified files
> > underneath those directories are committed.
> >
> > Does the git staging area provide any capability beyond this?
>
>
> AFAIK with git staging you can select specific changes in a single
> file as well, to commit only a sub-set of changes in that file.
>
>
> --
> Andreas Kupries
> Senior Tcl Developer
> Code to Cloud: Smarter, Safer, Faster™
> F: 778.786.1133
> andre...@activestate.com, http://www.activestate.com
> Learn about Stackato for Private PaaS: http://www.activestate.com/stackato
> ___
> 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] Is this a crazy idea?

[Abilio Marques]

By doing git commit -a, your doing an implicit

git add -A before the commit, which stages all the uncommitted changes, and
then you're working close to what you would in fossil.

But we're talking about the Linus dream:

You do some changes, then you select the files (not it seems that even line
by line changes are selectable) you want to include in the commit by doing
"git add", and then you commit.

Try this on an empty directory (I'm running by memory now, so don't believe
me completely):
git init
echo "line 1" > test.txt
git add test.txt
git commit -m "this is a test"
echo "line 2" >> test.txt
git status # You'll see it talks about unstaged changes by this point
git commit -m "another line in the test" # I believe it will refuse


On Thu, Mar 19, 2015 at 9:17 PM, Andy Bradford 
wrote:

> Thus said Abilio Marques on Thu, 19 Mar 2015 21:08:55 -0430:
>
> > (1) modify a file or files
> > (2) add the files (every single time... this sucks sometimes, as Joerg
> said)
> > (3) commit
>
> I'm not sure what (2) is unless you  mean that I create new files in the
> working checkout and  then use ``git add''  to add them. As  to why this
> would suck,  I'm not  sure, isn't  ``git add'' a  necessary evil  to get
> something into the repository?
>
> Here's my typical git day:
>
>   (1) modify or create file(s)
>   (1a) git add files if necessary
>   (2) review changes with git diff
>   (3) git commit -a (or git commit for a specific file if some changes
>   are not ready
>   (4) git pull; git push when ready
>
> So, let me ask this, if this means I'm using the staging area, why don't
> I feel like this is any different than how I use Fossil?
>
> Andy
> --
> TAI64 timestamp: 4000550b7c54
>
>
>
___
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] Is this a crazy idea?

[Andy Bradford]

Thus said Abilio Marques on Thu, 19 Mar 2015 21:08:55 -0430:

> (1) modify a file or files
> (2) add the files (every single time... this sucks sometimes, as Joerg said)
> (3) commit

I'm not sure what (2) is unless you  mean that I create new files in the
working checkout and  then use ``git add''  to add them. As  to why this
would suck,  I'm not  sure, isn't  ``git add'' a  necessary evil  to get
something into the repository?

Here's my typical git day:

  (1) modify or create file(s)
  (1a) git add files if necessary
  (2) review changes with git diff
  (3) git commit -a (or git commit for a specific file if some changes 
  are not ready
  (4) git pull; git push when ready

So, let me ask this, if this means I'm using the staging area, why don't
I feel like this is any different than how I use Fossil?

Andy
-- 
TAI64 timestamp: 4000550b7c54


___
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] Is this a crazy idea?

[Abilio Marques]

Do you follow the traditional?:

(1) modify a file or files
(2) add the files (every single time... this sucks sometimes, as Joerg said)
(3) commit

If the answer is yes, you're using the staging area... Cool things about
that... yes, you can select what to include (seems that line by line). See
my next email

On Thu, Mar 19, 2015 at 9:01 PM, Andy Bradford <
amb-sendok-1429407112.filllmkhpgbjfacbk...@bradfords.org> wrote:

> Thus said Abilio Marques on Thu, 19 Mar 2015 19:22:14 -0430:
>
> > Having said these things,  I must confess that in my  mind, I find the
> > staging area  a difference that's  not easily solved. Perhaps  some of
> > you have thought about this before,  and have ideas on how to simulate
> > it in a clean way. Any idea on my idea is welcomed.
>
> I've used  git for  a few years  now, but I've  never used  this beloved
> ``staging area,''  at least  not conciously.  What am  I missing  by not
> using the ``staging area?''
>
> Andy
> --
> TAI64 timestamp: 4000550b78ab
>
>
>
___
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] Is this a crazy idea?

[Andy Bradford]

Thus said Abilio Marques on Thu, 19 Mar 2015 19:22:14 -0430:

> Having said these things,  I must confess that in my  mind, I find the
> staging area  a difference that's  not easily solved. Perhaps  some of
> you have thought about this before,  and have ideas on how to simulate
> it in a clean way. Any idea on my idea is welcomed.

I've used  git for  a few years  now, but I've  never used  this beloved
``staging area,''  at least  not conciously.  What am  I missing  by not
using the ``staging area?''

Andy
-- 
TAI64 timestamp: 4000550b78ab


___
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] Is this a crazy idea?

[Joerg Sonnenberger]

On Thu, Mar 19, 2015 at 06:22:52PM -0600, Scott Robison wrote:
> I can't answer for Abilio, but given my recent increased experience with
> git due to workplace changes: the git folk seem to prefer the staging area
> because you're less likely to accidentally commit something you didn't mean
> to.

Ironically, from what I have seen it is the feature most likely to make
you commit something you didn't mean to. It is even more obnoxious than
the commit with explicit file list in all other systems -- it makes it
even easier to forgot parts with a dirty work directory.

Joerg
___
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] Is this a crazy idea?

[Abilio Marques]

will only commit changes in 1, and if you do git status, will tell you
about the modifications done in 3.

On Thu, Mar 19, 2015 at 8:38 PM, Richard Hipp  wrote:

> Further questions about staging area:
>
> If I do this:
>
>  (1)  Edit file xyzzy.txt
>  (2)  git add xyzzy.txt
>  (3)  More edits to xyzzy.txt
>  (4)  git commit
>
> Then does only the first set of edits to xyzzy.txt get committed, or
> do both edits (1) and (3) get committed?
> --
> 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] Is this a crazy idea?

[die.drachen]

> Further questions about staging area:
> 
> If I do this:
> 
> (1)  Edit file xyzzy.txt
> (2)  git add xyzzy.txt
> (3)  More edits to xyzzy.txt
> (4)  git commit
> 
> Then does only the first set of edits to xyzzy.txt get committed, or
> do both edits (1) and (3) get committed?

Only changes from step 1 are committed. After adding changes from step 1 to 
staging area then making more changes, a status looks like this:

Changes to be committed:
modified:   index.js

Changes not staged for commit:
modified:   index.js



___
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] Is this a crazy idea?

[Abilio Marques]

Really? didn't know that... I'm impressed by that. There've been times when
I've needed it, then proceeded to stash, then stash apply, then modified,
then committed, then stash popped and so on...

Unless you mean that you do a git add, the modify the same file, and commit
as is, without doing git add again... that way you can selectively commit a
sub-set, but depends on the moment you did the adds. Never heard of
selectivity.

I know it could be off topic (does it?), but how would you do that? Do you
have an example?

On Thu, Mar 19, 2015 at 8:28 PM, Andreas Kupries 
wrote:

> On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp  wrote:
> > On 3/19/15, Abilio Marques  wrote:
> >>
> >>  Most of the friends I've shown fossil to love the idea of having SCM,
> wiki
> >> and tickets in the same, tiny place. Looks promising for them... but
> then
> >> they miss the git staging area.
> >>
> >
> > Fossil does give you the ability to do a partial commit  (in case you
> > are really want to commit changes that you have not tested).  Just
> > list the subset of files you want to commit on the commit
> > command-line:
> >
> >   fossil commit one.txt two.txt dir-three/
> >
> > If you include directories in the list, then all modified files
> > underneath those directories are committed.
> >
> > Does the git staging area provide any capability beyond this?
>
>
> AFAIK with git staging you can select specific changes in a single
> file as well, to commit only a sub-set of changes in that file.
>
>
> --
> Andreas Kupries
> Senior Tcl Developer
> Code to Cloud: Smarter, Safer, Faster™
> F: 778.786.1133
> andre...@activestate.com, http://www.activestate.com
> Learn about Stackato for Private PaaS: http://www.activestate.com/stackato
> ___
> 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] Is this a crazy idea?

[Richard Hipp]

Further questions about staging area:

If I do this:

 (1)  Edit file xyzzy.txt
 (2)  git add xyzzy.txt
 (3)  More edits to xyzzy.txt
 (4)  git commit

Then does only the first set of edits to xyzzy.txt get committed, or
do both edits (1) and (3) get committed?
-- 
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] Is this a crazy idea?

[die.drachen]

I'm brand new to fossil but have used git some and mercurial even longer. When 
I'm working on a project I tend to poke around in the areas of code nearby to 
what my task directly involves - as a manner of investigating and learning.

The git staging area is useful to my workflow because I am often making changes 
and testing something, but later decide to have separate commits within all the 
changes. This helps preserve a nicer history where commits usually have 
single-responsibility. For example, fixing a null pointer in a button click 
handler, but also tweaking the button's sizing/border/etc. to be consistent 
within the UI. I would likely make those two changes at once and test locally, 
but ultimately have separate commits for each change. On other occasions where 
I might end up in a similar situations is when finding out one bug is actually 
multiple bugs.

It sounds like fossil is similar to mercurial - mercurial's commit command by 
default includes all local changes, but arguments can be specified for 
including/excluding files (or file patterns).

When I first started using git I was thrown off by having to include things 
into staging before committing, but I have started preferring the explicit 
nature of defining my commits that way.

Christopher
___
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] Is this a crazy idea?

[bch]

On 3/19/15, Andreas Kupries  wrote:
> On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp  wrote:
>> On 3/19/15, Abilio Marques  wrote:
>>>
>>>  Most of the friends I've shown fossil to love the idea of having SCM,
>>> wiki
>>> and tickets in the same, tiny place. Looks promising for them... but then
>>> they miss the git staging area.
>>>
>>
>> Fossil does give you the ability to do a partial commit  (in case you
>> are really want to commit changes that you have not tested).  Just
>> list the subset of files you want to commit on the commit
>> command-line:
>>
>>   fossil commit one.txt two.txt dir-three/
>>
>> If you include directories in the list, then all modified files
>> underneath those directories are committed.
>>
>> Does the git staging area provide any capability beyond this?
>
>
> AFAIK with git staging you can select specific changes in a single
> file as well, to commit only a sub-set of changes in that file.

*That* would be neat to have -- I've heard of it in git, but not
explored it. The next time that I end up w/ two logical ideas commited
w/ a single checkin won't be the first. Currently, if it's important
enough for me, what I do is [stash] the commit, generate a diff and
then selectively apply that diff in the appropriate number of steps,
committing ea. logical idea at a time.

Otherwise, re: staging area vs. fossil commit, it seems it's just a
matter of default include vs default deny as far as what gets
committed. One thing that would alleviate miscommitted collections of
files (or miscommitted anything) is the ability to [pop] off a branch
tip...


-bch



>
> --
> Andreas Kupries
> Senior Tcl Developer
> Code to Cloud: Smarter, Safer, Faster(tm)
> F: 778.786.1133
> andre...@activestate.com, http://www.activestate.com
> Learn about Stackato for Private PaaS: http://www.activestate.com/stackato
> ___
> 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] Is this a crazy idea?

[Andreas Kupries]

On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp  wrote:
> On 3/19/15, Abilio Marques  wrote:
>>
>>  Most of the friends I've shown fossil to love the idea of having SCM, wiki
>> and tickets in the same, tiny place. Looks promising for them... but then
>> they miss the git staging area.
>>
>
> Fossil does give you the ability to do a partial commit  (in case you
> are really want to commit changes that you have not tested).  Just
> list the subset of files you want to commit on the commit
> command-line:
>
>   fossil commit one.txt two.txt dir-three/
>
> If you include directories in the list, then all modified files
> underneath those directories are committed.
>
> Does the git staging area provide any capability beyond this?


AFAIK with git staging you can select specific changes in a single
file as well, to commit only a sub-set of changes in that file.


-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
F: 778.786.1133
andre...@activestate.com, http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato
___
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] Is this a crazy idea?

[Abilio Marques]

I was cooking dinner, so Scott wrote it first. Basically I agree with his
point of view. I must confess that historically, I first used fossil, then
git, so staging was actually weird for me at the beginning.

Then I kinda liked it for no apparent reason. It felt like it "simplified"
the partial commit, specially because I decided "this file SHOULD be in my
next commit, this shouldn't"... then went for lunch, came back... and the
list was still there. I could go home, get back the next day, and the list
was still there. In fossil, I must rewind all my work until the commit
moment, check the list of files, remember what was did what, and the
proceed to do a partial commit.

Then there is the fact to ensure right things committed on the right
branches. In my personal projects, there is one where I miss this thing a
lot. I keep my resume in LaTeX, and I do push the PDFs that are generated,
but only into trunk (not the other branches). I have to do partial commits
all the times.

Actually, about that, I've found myself in several other situations where I
want to add everything except 1 or 2 files... So a commit --ignore "these
files" would become handy. Specially because I can continue to do
"complete" commits (of different files) while ignoring the same two, by
repeating the command line on history, no changes at all, without having to
think too much each time.

Why staging area is so hip? I don't really know... I guess is a philosophy
thing, and most people come from git, so they are used to it, and is a
shock when they don't see it. I guess they feel like they will miss some
kind of freedom. Can you survive on fossil without it? totally... For most
of them (my git friends), the autosync is also a "how will I survive this"
moment, but then they discover they can turn it off, use it for a while
like that, then give it a shot again, and then live with it (some love it).




On Thu, Mar 19, 2015 at 7:52 PM, Scott Robison 
wrote:

> On Thu, Mar 19, 2015 at 6:14 PM, Richard Hipp  wrote:
>
>> On 3/19/15, Abilio Marques  wrote:
>> >
>> >  Most of the friends I've shown fossil to love the idea of having SCM,
>> wiki
>> > and tickets in the same, tiny place. Looks promising for them... but
>> then
>> > they miss the git staging area.
>> >
>>
>> Does the git staging area provide any capability beyond this?  Am I
>> missing something?
>>
>> Please help me to understand why people think that the git staging
>> area is a good idea.
>>
>
> I can't answer for Abilio, but given my recent increased experience with
> git due to workplace changes: the git folk seem to prefer the staging area
> because you're less likely to accidentally commit something you didn't mean
> to. Essentially, it seems like a "feature" for people who can't or don't
> want multiple open work areas so ensure the right things get committed on
> the right branches, since they very well may be working on multiple
> branches at the same time in the same tree.
>
> See this:
> http://stackoverflow.com/questions/6270193/multiple-working-directories-with-git
>
> The staging area can be disabled / skipped, but that's how it has been
> explained to me.
>
> --
> Scott Robison
>
>
> ___
> 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] Is this a crazy idea?

[Kees Nuyt]

[Default] On Thu, 19 Mar 2015 19:22:14 -0430, Abilio Marques 
 wrote:

> Having said these things, I must confess that in my mind, I find the
> staging area a difference that's not easily solved. Perhaps some of you
> have thought about this before, and have ideas on how to simulate it in a
> clean way. Any idea on my idea is welcomed.

Isn't that solved by the ability of fosil to have multiple checkouts
for the same repository, each in its own branch?
I agree it might be hard to write a shim for that.

-- 
Regards, Cordialement, Groet,

Kees Nuyt

___
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] Is this a crazy idea?

[Scott Robison]

On Thu, Mar 19, 2015 at 6:32 PM, Richard Hipp  wrote:

> On 3/19/15, Scott Robison  wrote:
> >
> > I can't answer for Abilio, but given my recent increased experience with
> > git due to workplace changes: the git folk seem to prefer the staging
> area
> > because you're less likely to accidentally commit something you didn't
> mean
> > to. Essentially, it seems like a "feature" for people who can't or don't
> > want multiple open work areas so ensure the right things get committed on
> > the right branches, since they very well may be working on multiple
> > branches at the same time in the same tree.
> >
>
> So the staging area is being used as a way of working around the fact
> that Git does not allow multiple independent check-outs against the
> same repository?  Am I understanding that correctly?
>

That is the best answer I've been given. I explained how I worked (in both
svn & fossil) on separate branches in separate directories, but received no
further feedback on that topic.

-- 
Scott Robison
___
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] Is this a crazy idea?

[Richard Hipp]

On 3/19/15, Scott Robison  wrote:
>
> I can't answer for Abilio, but given my recent increased experience with
> git due to workplace changes: the git folk seem to prefer the staging area
> because you're less likely to accidentally commit something you didn't mean
> to. Essentially, it seems like a "feature" for people who can't or don't
> want multiple open work areas so ensure the right things get committed on
> the right branches, since they very well may be working on multiple
> branches at the same time in the same tree.
>

So the staging area is being used as a way of working around the fact
that Git does not allow multiple independent check-outs against the
same repository?  Am I understanding that correctly?

-- 
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] Is this a crazy idea?

[Scott Robison]

On Thu, Mar 19, 2015 at 6:14 PM, Richard Hipp  wrote:

> On 3/19/15, Abilio Marques  wrote:
> >
> >  Most of the friends I've shown fossil to love the idea of having SCM,
> wiki
> > and tickets in the same, tiny place. Looks promising for them... but then
> > they miss the git staging area.
> >
>
> Does the git staging area provide any capability beyond this?  Am I
> missing something?
>
> Please help me to understand why people think that the git staging
> area is a good idea.
>

I can't answer for Abilio, but given my recent increased experience with
git due to workplace changes: the git folk seem to prefer the staging area
because you're less likely to accidentally commit something you didn't mean
to. Essentially, it seems like a "feature" for people who can't or don't
want multiple open work areas so ensure the right things get committed on
the right branches, since they very well may be working on multiple
branches at the same time in the same tree.

See this:
http://stackoverflow.com/questions/6270193/multiple-working-directories-with-git

The staging area can be disabled / skipped, but that's how it has been
explained to me.

-- 
Scott Robison
___
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] Is this a crazy idea?

[Richard Hipp]

On 3/19/15, Abilio Marques  wrote:
>
>  Most of the friends I've shown fossil to love the idea of having SCM, wiki
> and tickets in the same, tiny place. Looks promising for them... but then
> they miss the git staging area.
>

Fossil does give you the ability to do a partial commit  (in case you
are really want to commit changes that you have not tested).  Just
list the subset of files you want to commit on the commit
command-line:

  fossil commit one.txt two.txt dir-three/

If you include directories in the list, then all modified files
underneath those directories are committed.

Does the git staging area provide any capability beyond this?  Am I
missing something?

Please help me to understand why people think that the git staging
area is a good idea.
-- 
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] home directory must be writeable

[Scott Robison]

On Thu, Mar 19, 2015 at 5:45 PM, Richard Hipp  wrote:

> I remembered that change as having occurred years and years ago.  But
> upon consulting the timeline, I see that Joe put it in two months ago.
> I don't recall the exact reason.
>

Thanks Joe! This solves an annoyance for me.

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

[fossil-users] Is this a crazy idea?

[Abilio Marques]

This email has two "motivations".

First:

Through the years I've evangelized about several subjects. Most of them go
hand in hand with my philosophy that​ software tools (well, this is
applicable to everything in life) should be as simple as possible for the
task they are intended to be used. Actually is the user who must pick
wisely.

SQLite and Fossil are two of the greatest pieces of software I've come to
use because of that reason. I've seen people (even myself a long time ago)
using mysql server for applications with 4 tables and a single user until
they hear about SQLite, and they never look back.

 Most of the friends I've shown fossil to love the idea of having SCM, wiki
and tickets in the same, tiny place. Looks promising for them... but then
they miss the git staging area.

Second (and the most important one):

Several times I've toyed with the idea of writing a "shim" so fossil can be
used in place of git or subversion. Instead of writing a new plugin for
things like Qt Creator, Eclipse, TeXStudio and several others, task which
is too wide and time consuming, I can make them believe they are running
either git or subversion. In that way, any program compatible with git or
subversion (by means of running the command line version) becomes
compatible with fossil.

I think that will open the door to hundreds of applications, and this way
perhaps it will attract some new users to Fossil. Specially those in
Windows, where git and svn are harder to install than just a simple exe
download.

 I feel more comfortable writing the shim to GIT. Two reasons for that:
first, I see git userbase growing (so I believe programs will favor GIT).
Second, I've only used subversion in a couple of trivial situations.

Having said these things, I must confess that in my mind, I find the
staging area a difference that's not easily solved. Perhaps some of you
have thought about this before, and have ideas on how to simulate it in a
clean way. Any idea on my idea is welcomed.
___
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] home directory must be writeable

[Richard Hipp]

On 3/19/15, Abilio Marques  wrote:
> Yes indeed, and that's something new for me. It was documented just a few
> weeks ago. Thanks a lot! Looks cleaner that way.
>
> So someone was in my same situation, or is there another useful reason for
> having that var?

I remembered that change as having occurred years and years ago.  But
upon consulting the timeline, I see that Joe put it in two months ago.
I don't recall the exact reason.
-- 
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] home directory must be writeable

[Abilio Marques]

Yes indeed, and that's something new for me. It was documented just a few
weeks ago. Thanks a lot! Looks cleaner that way.

So someone was in my same situation, or is there another useful reason for
having that var?

On Thu, Mar 19, 2015 at 6:39 PM, Richard Hipp  wrote:

> On 3/19/15, Abilio Marques  wrote:
> > Actually they do allow (and sometimes encourage) you to connect over ssh,
> > and they have bash with history... but the file is written inside a
> > directory called $HOME/data (which is writeable).
>
> In your .bashrc script (wherever that is) can you just add a line that
> says:
>
> export FOSSIL_HOME=$HOME/data
>
> That will probably get it working better for you.
>
> >
> > Openshift is a nice service. I've used it for some time now, no issues
> > whatsoever, but (there is always a but)... sometimes they take the way
> > people normally work in UNIX, put it in a blender, and serve that. Even
> > regular applications like wordpress get completely modified beyond
> > recognition (I'm talking about directory structure).
> >
> > I suppose it has something to do with the fact they sell the product as a
> > PaaS, so it's easy to setup and run from the outside. Yet, under the
> hood,
> > they've got the most complicated ways to make it work. $HOME pointing to
> a
> > non writable directory goes with that philosophy.
> >
> > On Thu, Mar 19, 2015 at 5:58 PM, Stephan Beal 
> > wrote:
> >
> >> Presumably they don't expect users to use the shell, as the shell
> history
> >> is also (normally) saved in the home dir (except in some ultra-pedantic
> >> setups where the history is stored in a place where the user cannot
> >> access/edit it).
> >>
> >> - stephan
> >> Sent from a mobile device, possibly from bed. Please excuse brevity and
> >> typos.
> >> On Mar 19, 2015 11:24 PM, "Ron W"  wrote:
> >>
> >>> On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques 
> >>> wrote:
> >>>
>  But you're right, now that I think about it, is the only time I've
> ever
>  seen a home directory not owned by the corresponding user but by root.
> 
> >>>
> >>> Does the hosting service provide special commands for creating
> >>> directories and files in your home directory?
> >>>
> >>>
> >>> ___
> >>> 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
> >>
> >>
> >
>
>
> --
> 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] home directory must be writeable

[Richard Hipp]

On 3/19/15, Abilio Marques  wrote:
> Actually they do allow (and sometimes encourage) you to connect over ssh,
> and they have bash with history... but the file is written inside a
> directory called $HOME/data (which is writeable).

In your .bashrc script (wherever that is) can you just add a line that says:

export FOSSIL_HOME=$HOME/data

That will probably get it working better for you.

>
> Openshift is a nice service. I've used it for some time now, no issues
> whatsoever, but (there is always a but)... sometimes they take the way
> people normally work in UNIX, put it in a blender, and serve that. Even
> regular applications like wordpress get completely modified beyond
> recognition (I'm talking about directory structure).
>
> I suppose it has something to do with the fact they sell the product as a
> PaaS, so it's easy to setup and run from the outside. Yet, under the hood,
> they've got the most complicated ways to make it work. $HOME pointing to a
> non writable directory goes with that philosophy.
>
> On Thu, Mar 19, 2015 at 5:58 PM, Stephan Beal 
> wrote:
>
>> Presumably they don't expect users to use the shell, as the shell history
>> is also (normally) saved in the home dir (except in some ultra-pedantic
>> setups where the history is stored in a place where the user cannot
>> access/edit it).
>>
>> - stephan
>> Sent from a mobile device, possibly from bed. Please excuse brevity and
>> typos.
>> On Mar 19, 2015 11:24 PM, "Ron W"  wrote:
>>
>>> On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques 
>>> wrote:
>>>
 But you're right, now that I think about it, is the only time I've ever
 seen a home directory not owned by the corresponding user but by root.

>>>
>>> Does the hosting service provide special commands for creating
>>> directories and files in your home directory?
>>>
>>>
>>> ___
>>> 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
>>
>>
>


-- 
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] home directory must be writeable

[Abilio Marques]

Actually they do allow (and sometimes encourage) you to connect over ssh,
and they have bash with history... but the file is written inside a
directory called $HOME/data (which is writeable).

Openshift is a nice service. I've used it for some time now, no issues
whatsoever, but (there is always a but)... sometimes they take the way
people normally work in UNIX, put it in a blender, and serve that. Even
regular applications like wordpress get completely modified beyond
recognition (I'm talking about directory structure).

I suppose it has something to do with the fact they sell the product as a
PaaS, so it's easy to setup and run from the outside. Yet, under the hood,
they've got the most complicated ways to make it work. $HOME pointing to a
non writable directory goes with that philosophy.

On Thu, Mar 19, 2015 at 5:58 PM, Stephan Beal  wrote:

> Presumably they don't expect users to use the shell, as the shell history
> is also (normally) saved in the home dir (except in some ultra-pedantic
> setups where the history is stored in a place where the user cannot
> access/edit it).
>
> - stephan
> Sent from a mobile device, possibly from bed. Please excuse brevity and
> typos.
> On Mar 19, 2015 11:24 PM, "Ron W"  wrote:
>
>> On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques 
>> wrote:
>>
>>> But you're right, now that I think about it, is the only time I've ever
>>> seen a home directory not owned by the corresponding user but by root.
>>>
>>
>> Does the hosting service provide special commands for creating
>> directories and files in your home directory?
>>
>>
>> ___
>> 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] home directory must be writeable

[Abilio Marques]

Not that I'm aware of. I did some googling, and only found upset people,
but no justification, nor any kind of special commands.

On Thu, Mar 19, 2015 at 5:54 PM, Ron W  wrote:

> On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques 
> wrote:
>
>> But you're right, now that I think about it, is the only time I've ever
>> seen a home directory not owned by the corresponding user but by root.
>>
>
> Does the hosting service provide special commands for creating directories
> and files in your home directory?
>
>
> ___
> 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] home directory must be writeable

[Warren Young]

On Mar 19, 2015, at 4:14 PM, Abilio Marques  wrote:
> 
> I actually didn't know about the ALL command. That changes the things. I 
> believe I've gone over it every time I run fossil help, but never stopped to 
> learn more about it, so thanks for opening my eyes.

Yeah, “fossil all sync” is one of several features that make Fossil uncommonly 
nice to use.
___
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] home directory must be writeable

[Abilio Marques]

Here’s a thought: Someone on this list gave me the idea of aliasing
“fossil” to “f”.  I do it with a symlink instead of a shell alias so that
it works even in places like a Vim :! command.

Yeah,

After writing yesterday's email, I worked another half hour, and ended up
frustrated, so I did something similiar. That made the rest of the night
more pleasant. In openshift you normally use git, but I actually love
fossil, and as this is a personal project that has been running on a
Raspberry for like 3 years, I won't touch git.

Thanks

On Thu, Mar 19, 2015 at 5:51 PM, Warren Young  wrote:

> On Mar 18, 2015, at 5:08 PM, Abilio Marques  wrote:
> >
> > HOME=. ./fossil command
>
> Here’s a thought: Someone on this list gave me the idea of aliasing
> “fossil” to “f”.  I do it with a symlink instead of a shell alias so that
> it works even in places like a Vim :! command.
>
> If you were willing to develop such a habit, you could do it with a shell
> script instead, which could always set HOME to someplace writeable.
> ___
> 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] home directory must be writeable

[Stephan Beal]

Presumably they don't expect users to use the shell, as the shell history
is also (normally) saved in the home dir (except in some ultra-pedantic
setups where the history is stored in a place where the user cannot
access/edit it).

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity and
typos.
On Mar 19, 2015 11:24 PM, "Ron W"  wrote:

> On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques 
> wrote:
>
>> But you're right, now that I think about it, is the only time I've ever
>> seen a home directory not owned by the corresponding user but by root.
>>
>
> Does the hosting service provide special commands for creating directories
> and files in your home directory?
>
>
> ___
> 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] home directory must be writeable

[Ron W]

On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques  wrote:

> But you're right, now that I think about it, is the only time I've ever
> seen a home directory not owned by the corresponding user but by root.
>

Does the hosting service provide special commands for creating directories
and files in your home directory?
___
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] home directory must be writeable

[Warren Young]

On Mar 18, 2015, at 5:08 PM, Abilio Marques  wrote:
> 
> HOME=. ./fossil command

Here’s a thought: Someone on this list gave me the idea of aliasing “fossil” to 
“f”.  I do it with a symlink instead of a shell alias so that it works even in 
places like a Vim :! command.

If you were willing to develop such a habit, you could do it with a shell 
script instead, which could always set HOME to someplace writeable.
___
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 server for timeline will return empty result for some parameters max

[die.drachen]

I wasn't sure if my attachment made it through the mailing list. Is there an 
issue/report/task created for this which I can continue following instead of 
through the mailing list? I couldn't figure out how to create an issue on the 
fossil-scm site.

> On Mar 18, 2015, at 10:30 AM, die.drachen  wrote:
> 
> I attached the output (using lldb instead of gdb).
> 
> 
>> On Mar 18, 2015, at 8:12 AM, Richard Hipp  wrote:
>> 
>> On 3/18/15, die.drachen  wrote:
>>> Unfortunately I'm unable to distribute the repo, which is also quite large
>>> (~730mb .fossil file, >93k commits). Are there additional measures I can
>>> take to get diagnostic information?
>>> 
>> 
>> Compile your own Fossil from trunk sources, using options -O0 -g.
>> Then run "gdb fossil" and within gdb type:  "run test-http
>> REPOFILENAME" (filling in the appropriate filename, of course).  There
>> will be no prompt, but Fossil is waiting for input at this point.
>> Type:
>> 
>>   GET /timeline?n=421&y=all
>> 
>> with no leading spaces and the press Enter twice.  When you hit the
>> error, type "bt" and send me the output.
>> -- 
>> 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] home directory must be writeable

[Abilio Marques]

Yeah, I know home directory MUST be writable. I do fight with that all the
time. I've always guessed is some sort of weird security thing. Never
asked. I'm not asking fossil to change because of that. As you say, is an
OpenShift issue.

Just thought fossil was of better use without global config that not usable
at all. But you're right, now that I think about it, is the only time I've
ever seen a home directory not owned by the corresponding user but by root.

Even when I knew about the global config, I actually didn't know about the
ALL command. That changes the things. I believe I've gone over it every
time I run fossil help, but never stopped to learn more about it, so thanks
for opening my eyes.



On Thu, Mar 19, 2015 at 4:14 PM, Warren Young  wrote:

> On Mar 18, 2015, at 5:04 PM, Abilio Marques  wrote:
>
>
> *home directory /var/lib/openshift/54fb48714382ecec88eb/ must be
> writeable*
>
>
> That sounds like just cause to complain to OpenShift tech support.
> There’s no good justification for $HOME to be read-only on a web platform
> provider.  You’re renting that space.
>
> I see it writes a .fossil file (sqlite database), but is it that important?
>
>
> According to this, yes, it’s somewhat important:
>
>   http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki
>
> By giving Fossil a place to write that file, you give it a place to store
> global settings and to remember which Fossils it has opened, so that
> commands like “fossil all sync” work as expected.
>
> ___
> 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] home directory must be writeable

[Warren Young]

On Mar 18, 2015, at 5:04 PM, Abilio Marques  wrote:
> 
> home directory /var/lib/openshift/54fb48714382ecec88eb/ must be writeable

That sounds like just cause to complain to OpenShift tech support.  There’s no 
good justification for $HOME to be read-only on a web platform provider.  
You’re renting that space.

> I see it writes a .fossil file (sqlite database), but is it that important?

According to this, yes, it’s somewhat important:

  http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki 


By giving Fossil a place to write that file, you give it a place to store 
global settings and to remember which Fossils it has opened, so that commands 
like “fossil all sync” work as expected.___
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 ui not working with recent chrome browser

[a...@gmx-topmail.de]

Am 19.03.2015 um 16:53 schrieb Richard Hipp:
> 
> I've also been reading in RFC 7230.  The more I read, the more I
> believe this is a Chrome bug.

I think I have found the cause of my problems: it seems indeed to be the
virus scanner. It feels embarassing that it looks quite obvious now, my
sole excuse is that I was missinterpreting the term "completely switched
off": for my scanner (it even wanted a reboot!) that means "provide no
protection but still break the system", which I probably should have
known (?).

I now found that I can exclude certain executables and IP
addresses from the http protocol checks it does. If I do that for one of
the browsers or for 127.0.0.1 that solves the problems (for those
browsers I exclude there respectively all browsers accessing local
repos). I have filed a bug report to the vendor.

I now think I can also understand that my test with other local
webservers did not show the problem: they just didn't compress.

Why firefox was not seeing the problem is still out of
my understanding (probably the standard browser is treated as an
exception from my scanner? who knowns...), but...

... fossil definitely does nothing wrong and has not been the cause of
my problems.

Thanks once more and sorry for the false alarm,

Albert

___
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] same port in use by concurrent fossil instances

[Andy Bradford]

Thus said Tontyna on Thu, 19 Mar 2015 11:58:40 +0100:

> Starting several fossil servers with "ui" increments port from 8080 onwards.
> Starting several fossil servers with "server" increments port ditto.
> Mixing "ui" and "server" instances results in double-bound ports.
> Don't know whether that's a Windows-only issue.

This  is not  a  Windows-only  behavior. The  server  does  not use  any
specific IP  and in  fact uses  any (0.0.0.0) as  shown in  your netstat
output. Whereas  ui wants to be  on 127.0.0.1 to restrict  access to the
local machine  only. 127.0.0.1 is  more specific,  so your OS  allows it
(OpenBSD allows it to). There is no double-binding going on here. If you
had 10 IP addresses you could have 10 things all listening on port 8080.

If you point your browser to  127.0.0.1:8080 you'll get the UI instance.
If  you point  your browser  to 192.168.1.10:8080  (or whatever  your IP
happens to be) I imagine you'll get the server.

Andy
--
TAI64 timestamp: 4000550b1748
___
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] Possible Bug in Merge Conflict Blocks

[Scott Robison]

On Thu, Mar 19, 2015 at 9:32 AM, bch  wrote:

> > The reality is that nothing can be perfect for 100% of all possible use
> cases, and in this particular case, I just got unlucky. The merge conflict
> information as given couldn't support a mechanical "pick one or the other"
> resolution (which was fine because this particular merge needed a thought
> out solution, not a mechanical resolution).
>
> This is what I was leaning toward.
>
> > I'm inclined to just leave it alone and live with the reality. Sorry for
> yelling fire (or whatever).
>
> Thanks for filling a reasonable report - I think the next step is
> developing a *workflow* that illustrates what's going on: i.e.: select you
> edits, run a diff to see what the changes really are. One thing that struck
> me is that code references (i.e.: "last common ancestor") could stand to
> have their SHA1 identifier included in the header so I've got it for
> immediate reference.
>
And to be clear that's the sort of thing I do (and what is typically
necessary). As I've thought more about it, I think the reason for the
disconnect for me in my head (not having dealt much with merge conflicts in
the past) is that the merge conflict block greatly resembles a diff between
two revisions, yet it is not a traditional diff (and thus does not replace
the need for actual analysis via traditional diff between the baseline &
each of the two descendants, possibly more).

No biggie. Just a little embarrassment for crying wolf. But the good thing
is that I understand the merging code and rationale a lot better now than I
did 24 hours ago. :)

-- 
Scott Robison
___
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 ui not working with recent chrome browser

[Joerg Sonnenberger]

On Thu, Mar 19, 2015 at 12:56:02PM -0400, Ron W wrote:
> I think there is some confusion of "Content-Encoding" vs "Transfer-Encoding"

Content-Encoding is gzip, Transfer-Encoding should be unset as Fossil
doesn't do HTTP/1.1 Chunked Transfers.

Joerg
___
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 ui not working with recent chrome browser

[Ron W]

On Thu, Mar 19, 2015 at 11:53 AM, Richard Hipp  wrote:

> On 3/19/15, Joerg Sonnenberger  wrote:
> > On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote:
> >> On 3/19/15, Joerg Sonnenberger  wrote:
> >> > On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
> >> >> On 3/19/15, a...@gmx-topmail.de  wrote:
> >> >> > Content-Encoding: gzip
> >> >> > Content-Length: 1516
> >> >> >
> >> >>
> >> >> So the question becomes:  Should the Content-Length be the length of
> >> >> the content before or after compression?
> >> >
> >> > Before aka after decompression.
> >> >
> >>
> >> Can you provide support for this assertion?
> >
> > Hm. Reading RFC 2616 again, I think I have to retract that. See the last
> > paragraph of 4.4.
> >
>
> I've also been reading in RFC 7230.  The more I read, the more I
> believe this is a Chrome bug.


I think there is some confusion of "Content-Encoding" vs "Transfer-Encoding"

>From RFC7230, section3.3.1:
Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]),
   Transfer-Encoding is a property of the message, not of the
   representation, and any recipient along the request/response chain
   MAY decode the received transfer coding(s) or apply additional
   transfer coding(s) to the message body, assuming that corresponding
   changes are made to the Transfer-Encoding field-value.

>From this, I would interpret "Content-Length" as being the size, in octets,
of the content after "Content-Encoding" is applied.

Further, section 3.3.2 says:
A sender MUST NOT send a Content-Length header field in any message
   that contains a Transfer-Encoding header field.

To me, this reinforces my above interpretation of "Content-Length"

My guess would a proxy bug. Albert's recent messages seem to support this.
___
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 ui not working with recent chrome browser

[Stephan Beal]

On Thu, Mar 19, 2015 at 4:53 PM, Richard Hipp  wrote:

> I've also been reading in RFC 7230.  The more I read, the more I
> believe this is a Chrome bug.
>

http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4

is pretty unambiguous:

"The transfer-length of a message is the length of the message-body as it
appears in the message; that is, after any transfer-codings have been
applied."

That's the transfer-length (which fossil doesn't set IIRC), followed by
this note:

"If a Content-Length header field (section 14.13
) is
present, its decimal value in OCTETs represents both the entity-length and
the transfer-length.  The Content-Length header field MUST NOT be sent if
these two lengths are different "

i.e. Content-length == transfer-length, _after_ any transfer encoding
(compression).

Section 14.13 says:

"The Content-Length entity-header field indicates the size of the
entity-body, in decimal number of OCTETs, sent to the recipient"

i concur that it's a bug in the OP's Chrome version.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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 ui not working with recent chrome browser

[a...@gmx-topmail.de]

Am 19.03.2015 um 16:53 schrieb Richard Hipp:
> On 3/19/15, Joerg Sonnenberger  wrote:
>> On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote:
>>> On 3/19/15, Joerg Sonnenberger  wrote:
 On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
> On 3/19/15, a...@gmx-topmail.de  wrote:
>> Content-Encoding: gzip
>> Content-Length: 1516
>>
>
> So the question becomes:  Should the Content-Length be the length of
> the content before or after compression?

 Before aka after decompression.

>>>
>>> Can you provide support for this assertion?
>>
>> Hm. Reading RFC 2616 again, I think I have to retract that. See the last
>> paragraph of 4.4.
>>
> 
> I've also been reading in RFC 7230.  The more I read, the more I
> believe this is a Chrome bug.
> 

honestly, I think that there is some other component or some special
settings on my computer which is buggy or wrong, not chrome as such
(especially as opera and ie have the same problem, and all only on my
computer). I'd imagine that there'd be storm of protest we'd be aware of
if the latest release of chrome would show incomplete pages for every
compressed http content it tries to show :-)

Most plausible seems something like the virus scanner which might
uncompress to see what's in the content. As I mentioned elsewhere
switching that off was one of the first things I tried (even before
reporting here) but that didn't help then. But I think I should check
that once more, and probably there are other components on my system
which think they also need to look into my http traffic...

I think if you're reasonably sure that fossil is doing the correct thing
and I'm the only one that is seeing it then there is no reason to change
anything. Sorry if I have created unnecessary fuss with my question...

Albert
___
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 ui not working with recent chrome browser

[a...@gmx-topmail.de]

Am 19.03.2015 um 15:19 schrieb Thomas Schnurrenberger:
> On 14.03.2015 13:12, a...@gmx-topmail.de wrote:
>>
>> I am having problems to access my local fossil repositories with a
>> recent versions of chrome, it looks like only part of the html code is
>> served by the standalone webserver.
>>
>> My question is whether this is a known problem and others can verify it
>> with a similar setup.
>>
> 
> Is there a virus scanner sitting between the network and the browser,
> like a local proxy?

yes, I think so. But it was one of my first tries to check whether I'd
see the problem also when switching off the virus-protection and
firewall. It did not change things for me then, but honestly I'm always
somewhat unsure if I really did switch off everything on Windows systems
when the corresponding GUIs tell me so. So I'll probably try that again...

Albert
___
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 ui not working with recent chrome browser

[Richard Hipp]

On 3/19/15, Joerg Sonnenberger  wrote:
> On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote:
>> On 3/19/15, Joerg Sonnenberger  wrote:
>> > On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
>> >> On 3/19/15, a...@gmx-topmail.de  wrote:
>> >> > Content-Encoding: gzip
>> >> > Content-Length: 1516
>> >> >
>> >>
>> >> So the question becomes:  Should the Content-Length be the length of
>> >> the content before or after compression?
>> >
>> > Before aka after decompression.
>> >
>>
>> Can you provide support for this assertion?
>
> Hm. Reading RFC 2616 again, I think I have to retract that. See the last
> paragraph of 4.4.
>

I've also been reading in RFC 7230.  The more I read, the more I
believe this is a Chrome 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] Possible Bug in Merge Conflict Blocks

[bch]

On Mar 19, 2015 12:40 AM, "Scott Robison"  wrote:
>
> On Wed, Mar 18, 2015 at 5:41 PM, bch  wrote:
>>
>> I tried this, and I see what you're talking about -- It's not clear to
>> me it's an error (I'm not apologizing for anything that happened here,
>> but I'd have to better understand the merge algorithm to know if this
>> is logically sane). Its easy to see how this could be confusing
>> though. I'll have to fiddle more to understand this.
>
>
> Okay, here's what I have come up with.
>
> 1. It is not a bug. It is technically accurate, though confusing, because
it doesn't allow you to easily "use original" or "use merge" because of the
missing line.
>
> 2. The "problem" (in my expectation, not fossil) is one of context. I
made a little test change to force at least one extra line of context at
the end of the conflict block and that gives me what I was expecting.
However, I can see where this "problem" could probably crop up with
inadequate context at the beginning of the conflict instead of at the end,
or that perhaps one extra line of context still wouldn't be enough, or
could even be too much.
>
> The reality is that nothing can be perfect for 100% of all possible use
cases, and in this particular case, I just got unlucky. The merge conflict
information as given couldn't support a mechanical "pick one or the other"
resolution (which was fine because this particular merge needed a thought
out solution, not a mechanical resolution).

This is what I was leaning toward.

> I'm inclined to just leave it alone and live with the reality. Sorry for
yelling fire (or whatever).

Thanks for filling a reasonable report - I think the next step is
developing a *workflow* that illustrates what's going on: i.e.: select you
edits, run a diff to see what the changes really are. One thing that struck
me is that code references (i.e.: "last common ancestor") could stand to
have their SHA1 identifier included in the header so I've got it for
immediate reference.

> SDR
>
> ___
> 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 ui not working with recent chrome browser

[Joerg Sonnenberger]

On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote:
> On 3/19/15, Joerg Sonnenberger  wrote:
> > On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
> >> On 3/19/15, a...@gmx-topmail.de  wrote:
> >> > Content-Encoding: gzip
> >> > Content-Length: 1516
> >> >
> >>
> >> So the question becomes:  Should the Content-Length be the length of
> >> the content before or after compression?
> >
> > Before aka after decompression.
> >
> 
> Can you provide support for this assertion?

Hm. Reading RFC 2616 again, I think I have to retract that. See the last
paragraph of 4.4.

Joerg
___
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 ui not working with recent chrome browser

[Thomas Schnurrenberger]

On 14.03.2015 13:12, a...@gmx-topmail.de wrote:


I am having problems to access my local fossil repositories with a
recent versions of chrome, it looks like only part of the html code is
served by the standalone webserver.

My question is whether this is a known problem and others can verify it
with a similar setup.



Is there a virus scanner sitting between the network and the browser,
like a local proxy?

--
tsbg


___
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 ui not working with recent chrome browser

[Richard Hipp]

On 3/19/15, Joerg Sonnenberger  wrote:
> On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
>> On 3/19/15, a...@gmx-topmail.de  wrote:
>> > Content-Encoding: gzip
>> > Content-Length: 1516
>> >
>>
>> So the question becomes:  Should the Content-Length be the length of
>> the content before or after compression?
>
> Before aka after decompression.
>

Can you provide support for this assertion?

-- 
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 ui not working with recent chrome browser

[Joerg Sonnenberger]

On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
> On 3/19/15, a...@gmx-topmail.de  wrote:
> > Content-Encoding: gzip
> > Content-Length: 1516
> >
> 
> So the question becomes:  Should the Content-Length be the length of
> the content before or after compression?

Before aka after decompression.

Joerg
___
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 ui not working with recent chrome browser

[Richard Hipp]

On 3/19/15, a...@gmx-topmail.de  wrote:
> Content-Encoding: gzip
> Content-Length: 1516
>

So the question becomes:  Should the Content-Length be the length of
the content before or after compression?

Fossil inherited the code for this from CVSTrac, which has always set
the Content-Length to be the number of bytes of content sent over the
wire (the size after compression).  And that interpretation has never
before given trouble in 13 years of prior use.

The W3C documentation on the issue is ambiguous and confused.

A web search shows numerous discussions of the problem with lots of
debate on both sides and no clear resolution of the issue.  Though I
did find https://bugs.php.net/bug.php?id=44164 which seems to imply
that Fossil is doing it correctly.

In the absence of additional information, therefore, I'm going to call
this a bug in Chrome.

-- 
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 ui not working with recent chrome browser

[a...@gmx-topmail.de]

Am 19.03.2015 um 00:01 schrieb a...@gmx-topmail.de:
> Am 18.03.2015 um 00:28 schrieb Tontyna:
 If that happened on my computer I'd recompile Fossil, commenting out the
 line #165 in winhttp.c :
 --  file_delete(zReplyFName);
 and have a look at the `fossil_server_P*_out*.txt` files.
>>>
>>> that's a good point. As I don't usually compile myself it might take a
>>> little before I can report what the outcome is...
>>>
>> Did it right now. If you want I can e-mail the tweaked fossil.exe to you.
>> You won't be really happy with the contents of the replyfiles. Fossil
>> produces 'Content-Encoding: gzip'.
>> But at least you can watch what files are produced when Firefox resp.
>> Chrome requests the same page and compare their 'Content-Length'.
> 
> Yes, I would like to try that on my machine...

Thanks to Tontya, who sent such a precompiled binary to me I could now
get some steps forward in understanding the problem. When looking at the
leftover textfiles there is no difference between the files sent to
firefox and those sent to the other browsers. But I found that these are
gzip compressed with headers like this:

HTTP/1.0 200 OK
Date: Thu, 19 Mar 2015 12:48:01 GMT
Connection: close
X-UA-Compatible: IE=edge
X-Frame-Options: SAMEORIGIN
Cache-control: no-cache
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 1516

My first idea was that I'd try what happens when I'd disable gzip
compression on the server side, but found no switch for that in fossil
(is there any?). When I disabled gzip compression on the client side
(for chrome I did change the accept-encoding header with the modheader
extension) it turned out that now I receive complete pages again.

When I extracted "Content-Length" bytes of the files with the
uncompressed html-code with something like:

tail -114 fossil_server_P8080__out28.txt | head -c 1516

(first tail cuts out the header), I got exactly that truncated part of
the page source that chrome (and ie and opera) report when looking at
the truncated page sources. So it looks like these browsers (or any
component that does the uncompress, at least on my machine?!?) interpret
the content length as the length of the uncompressed content and cut off
the rest (probably some kind of security measure?) while firefox either
ignores the Content-Length or interprets it as the length of the
compressed content.

I don't know what the official specs are concerning Content-Length and
whether the one or the other behavior is correct, why it has changed on
my machines about two weeks ago and I wonder even more that no one else
sees these problems. But I do now have another workaround (switch of
compression which is probably even advantageous when looking at local
repos), so for me the problem has lost urgency a lot and it seems to be
exoctic when it's just me who has it, so I can understand if you decide
to ignore it. But if anyone with more knowledge about the details of
http details wants to investigate this further, I will be happy to
provide any further details that would help to fully understand what
goes wrong and if fossil can (should?) do anything about it.

Thanks for your help and thanks for fossil,

Albert

PS: I was asked to prepare a public repository so others could have a
look at it. As I (and I think at least also Tontyna) now believe that
the problem isn't with the repository my impression is this probably is
not necessary anymore. But if that impression is wrong I could now
create such a public repository and send the IP and port to those who
asked and who'd still like to have a look at it

___
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] Got Ubuntu PPA for fossil-releases up and running

[Oliver Friedrich]

These scripts are called recipes. I checked it in into my second branch
that keeps the packaging information.

The recipes that are actually used are only in launchpad and not stored in
the repository itself, anyway, you can look at it here:
https://bazaar.launchpad.net/~beowulfof/+junk/fossil-packaging/view/head:/debian/fossil.recipe

I followed this very nice screencast of the launchpad team:
https://www.youtube.com/watch?v=_bG-SXNX9Ww&feature=youtu.be




Vikrant Chaudhary  schrieb am Do., 19. März 2015 um
12:41 Uhr:

> Nice! Btw where can I see the build script that is fed to Launchpad's
> automated build services?
>
> Cheers.
> - Vikrant
>
>
> On 19 March 2015 at 17:01, Oliver Friedrich
>  wrote:
> > I hope you don't mind that I got up an Ubuntu PPA for current fossil
> > releases. This was merely a testing thing for me, to build learn how to
> > handle a personal package archive - addiotionally it nagged me, that the
> > currently shipped version of fossil in ubuntu is failry outdated.
> >
> > This PPA uses launchpad new automated build services, so it should give
> you
> > the latest debs a little after I import the next stable release.
> >
> > Currently supported are the ubuntu-releases vivid, utopic and trusty.
> >
> > More info about the PPA on Launchpad:
> > https://launchpad.net/~beowulfof/+archive/ubuntu/fossil-scm
> >
> > ppa:beowulfof/fossil-scm
> >
> > greetings
> >
> > Oliver
> >
> > ___
> > 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] same port in use by concurrent fossil instances

[Richard Hipp]

On 3/19/15, Tontyna  wrote:
> Starting several fossil servers with "ui" increments port from 8080 onwards.
> Starting several fossil servers with "server" increments port ditto.
> Mixing "ui" and "server" instances results in double-bound ports.
> Don't know whether that's a Windows-only issue.
>
> Example: When running `fossil server REPO_A` and `fossil ui REPO_B` at
> the same time both HTTP server instances will listen on port 8080.
>
> Experts will tell you that this is impossible and against builtin socket
> behaviour, bind() or listen() would never ever allow it, but that's what
> happens:

The combination if IP address and TCP port must be unique.  In this
case, you have two instances of Fossil listening on the same TCP port,
but using a different IP address.  The "fossil server" is listening on
the external IP address, apparently, and "fossil ui" is listening on
the loopback address.  HTTP requests from other machines should go to
"fossil server" and HTTP requests from the local machine should go to
"fossil ui".

At least that is the way I read this.

>
> C:\Oblong\fossiltest>netstat -ano | find ":8080"
>TCP0.0.0.0:8080   0.0.0.0:0ABHÖREN 6516
>TCP127.0.0.1:8080 0.0.0.0:0ABHÖREN 7312
>
> PID 6516 and PID 7312 listening on 8080.
>
> Consequence is that REPO_A isn't accessible via HTTP. All
> http://localhost:8080/* requests go to the REPO_B server. When you close
> the REPO_B instance REPO_A magically reappears.
>
> I formerly underwent that double-bind-port feature in non-fossil context
> where -- depending on circumstances only heaven knows -- sometimes the
> first an sometimes the second server instance responded to requests on
> the port involved. Our TCP clients experienced funny mixed-up conversations.
> Seems that double-bind only happens for executables having the same base
> name (e.g. "myTCPserver.exe" or "fossil.exe", different full paths don't
> matter).
> To prevent the double-bind we finally implemented a function PortInUse()
> which parses the output of `netstat`.
>
> Only workaround so far:
> Avoid "ui" and "server" at the same time and/or apply a --port below
> 8080 to your `fossil server`.
>
> - Tontyna
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>


-- 
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] Got Ubuntu PPA for fossil-releases up and running

[Vikrant Chaudhary]

Nice! Btw where can I see the build script that is fed to Launchpad's
automated build services?

Cheers.
- Vikrant


On 19 March 2015 at 17:01, Oliver Friedrich
 wrote:
> I hope you don't mind that I got up an Ubuntu PPA for current fossil
> releases. This was merely a testing thing for me, to build learn how to
> handle a personal package archive - addiotionally it nagged me, that the
> currently shipped version of fossil in ubuntu is failry outdated.
>
> This PPA uses launchpad new automated build services, so it should give you
> the latest debs a little after I import the next stable release.
>
> Currently supported are the ubuntu-releases vivid, utopic and trusty.
>
> More info about the PPA on Launchpad:
> https://launchpad.net/~beowulfof/+archive/ubuntu/fossil-scm
>
> ppa:beowulfof/fossil-scm
>
> greetings
>
> Oliver
>
> ___
> 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] Got Ubuntu PPA for fossil-releases up and running

[Oliver Friedrich]

I hope you don't mind that I got up an Ubuntu PPA for current fossil
releases. This was merely a testing thing for me, to build learn how to
handle a personal package archive - addiotionally it nagged me, that the
currently shipped version of fossil in ubuntu is failry outdated.

This PPA uses launchpad new automated build services, so it should give you
the latest debs a little after I import the next stable release.

Currently supported are the ubuntu-releases vivid, utopic and trusty.

More info about the PPA on Launchpad:
https://launchpad.net/~beowulfof/+archive/ubuntu/fossil-scm

ppa:beowulfof/fossil-scm

greetings

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

[fossil-users] same port in use by concurrent fossil instances

[Tontyna]

Starting several fossil servers with "ui" increments port from 8080 onwards.
Starting several fossil servers with "server" increments port ditto.
Mixing "ui" and "server" instances results in double-bound ports.
Don't know whether that's a Windows-only issue.

Example: When running `fossil server REPO_A` and `fossil ui REPO_B` at 
the same time both HTTP server instances will listen on port 8080.


Experts will tell you that this is impossible and against builtin socket 
behaviour, bind() or listen() would never ever allow it, but that's what 
happens:


C:\Oblong\fossiltest>netstat -ano | find ":8080"
  TCP0.0.0.0:8080   0.0.0.0:0ABHÖREN 6516
  TCP127.0.0.1:8080 0.0.0.0:0ABHÖREN 7312

PID 6516 and PID 7312 listening on 8080.

Consequence is that REPO_A isn't accessible via HTTP. All 
http://localhost:8080/* requests go to the REPO_B server. When you close 
the REPO_B instance REPO_A magically reappears.


I formerly underwent that double-bind-port feature in non-fossil context 
where -- depending on circumstances only heaven knows -- sometimes the 
first an sometimes the second server instance responded to requests on 
the port involved. Our TCP clients experienced funny mixed-up conversations.
Seems that double-bind only happens for executables having the same base 
name (e.g. "myTCPserver.exe" or "fossil.exe", different full paths don't 
matter).
To prevent the double-bind we finally implemented a function PortInUse() 
which parses the output of `netstat`.


Only workaround so far:
Avoid "ui" and "server" at the same time and/or apply a --port below 
8080 to your `fossil server`.


- Tontyna
___
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] Possible Bug in Merge Conflict Blocks

[Scott Robison]

On Wed, Mar 18, 2015 at 5:41 PM, bch  wrote:

> I tried this, and I see what you're talking about -- It's not clear to
> me it's an error (I'm not apologizing for anything that happened here,
> but I'd have to better understand the merge algorithm to know if this
> is logically sane). Its easy to see how this could be confusing
> though. I'll have to fiddle more to understand this.
>

Okay, here's what I have come up with.

1. It is not a bug. It is technically accurate, though confusing, because
it doesn't allow you to easily "use original" or "use merge" because of the
missing line.

2. The "problem" (in my expectation, not fossil) is one of context. I made
a little test change to force at least one extra line of context at the end
of the conflict block and that gives me what I was expecting. However, I
can see where this "problem" could probably crop up with inadequate context
at the beginning of the conflict instead of at the end, or that perhaps one
extra line of context still wouldn't be enough, or could even be too much.

The reality is that nothing can be perfect for 100% of all possible use
cases, and in this particular case, I just got unlucky. The merge conflict
information as given couldn't support a mechanical "pick one or the other"
resolution (which was fine because this particular merge needed a thought
out solution, not a mechanical resolution).

I'm inclined to just leave it alone and live with the reality. Sorry for
yelling fire (or whatever).

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