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 s
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
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 laun
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 buil
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.
>
>
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-pack
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.
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 th
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 deco
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 befo
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
w
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 que
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 al
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
>> >> > Co
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
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
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 m
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..
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
___
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
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'
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 e
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 r
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 th
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 w
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 de
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
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
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 somethi
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
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
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
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
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 Marque
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 occ
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. Actu
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 Robis
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
a
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.
> >
>
>
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
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
[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
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 co
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
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
>>>
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 ofte
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
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
> 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?
O
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) Mor
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.
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 wa
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
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''
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
b
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
fav
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 s
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 m
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 us
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
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 me
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 ad
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 certa
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 cor
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.
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 ancesto
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 mistak
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,
> f
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 o
69 matches
Mail list logo
