On Sun, Jan 13, 2013 at 6:58 PM, Richard Hipp wrote:
>
> On Sun, Jan 13, 2013 at 7:10 AM, Richard Hipp wrote:
>
>>
>> http://chronicleoutdoors.com/wp-content/gallery/cougar-photo/mountainlion.jpg
>>
>>
>> I'll see what I can do about enhancing Fossil with an "approaching puma"
>> warning (warnin
On Sun, Jan 13, 2013 at 7:10 AM, Richard Hipp wrote:
>
> http://chronicleoutdoors.com/wp-content/gallery/cougar-photo/mountainlion.jpg
>
> I'll see what I can do about enhancing Fossil with an "approaching puma"
> warning (warnings that a fork has occurred) and a "shoot puma with sidearm"
> comma
On Sun, 13 Jan 2013 20:36:50 +0100, Ramon Ribó wrote:
> >There is no rollback, an commit has been done. I >suppose you mean
> >to reverse the commit
>
> I know it is not there. This is exactly the reason for me to write this
> email.
Sorry for being less than clear - I mean that a rollback is n
>There is no rollback, an commit has been done. I >suppose you mean
>to reverse the commit
I know it is not there. This is exactly the reason for me to write this
email.
My proposal would of course require some kind of rollback or undo for the
commit that would be automatically executed when dete
On Sun, 13 Jan 2013 07:48:59 +0200,
John Found wrote:
> On Sat, 12 Jan 2013 21:22:28 -0800
> "Michael L. Barrow" wrote:
>
> >
> > Please stop trolling
> >
>
> I am not trolling.
I am prepared to believe you but I can see how tone and content might
make people believe that.
> It is "Redu
On Sun, 13 Jan 2013 16:35:11 +0100, Ramon Ribó wrote:
> In my opinion, the solution is more simple. Instead of:
>
> - sync
> - stop if would fork
> - commit
> - sync
>
> The procedure should be:
>
> - commit
> - sync
> - rollback if would fork
There is no rollback, an commit has been done. I
On Sun, Jan 13, 2013 at 5:10 AM, Richard Hipp wrote:
>
>
> On Sun, Jan 13, 2013 at 1:45 AM, Matt Welland wrote:
>
>>
>>
>>
>> On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp wrote:
>>
>>
>> Curious response. Did you intend to be insulting? I'm working with a
>> bunch of very smart people
>>
>
> N
In my opinion, the solution is more simple. Instead of:
- sync
- stop if would fork
- commit
- sync
The procedure should be:
- commit
- sync
- rollback if would fork
Ramon Ribó
El 13/01/2013 13:11, "Richard Hipp" va escriure:
>
>
> On Sun, Jan 13, 2013 at 1:45 AM, Matt Welland wrote:
>
>>
>>
On Sun, Jan 13, 2013 at 1:45 AM, Matt Welland wrote:
>
>
>
> On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp wrote:
>
>
> Curious response. Did you intend to be insulting? I'm working with a bunch
> of very smart people
>
No insult intended. It's the smart people who have the greatest tendency
t
just my 2 cents:
1.
I agree that it should be easier (or occuring even automatically?) to
merge such random forks. the `monotone' example was given. `hg' is another
obvious one doing that painlessly.
2.
I agree that improvement of the CLI is not given enough attention in
comparison to the
On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp wrote:
>
>
> On Sat, Jan 12, 2013 at 6:41 PM, Matt Welland wrote:
>
>> This is with regards to the problem described here:
>>
>>
>> http://lists.fossil-scm.org:8080/pipermail/fossil-users/2008-February/60.html
>>
>> We are seeing on the order of
On 01/12/2013 09:48 PM, John Found wrote:
I am not trolling. It is "Reductio ad absurdum" that proves D. Richard
Hipp is wrong in his statement. Solving technical problems by
high-handed methods is wrong by definition.
The source is available, so you should feel free to download and add in
t
On Sat, 12 Jan 2013 21:22:28 -0800
"Michael L. Barrow" wrote:
>
> Please stop trolling
>
I am not trolling. It is "Reductio ad absurdum" that proves D. Richard Hipp is
wrong in his statement.
Solving technical problems by high-handed methods is wrong by definition.
--
John Found
http
On 01/12/2013 09:22 PM, John Found wrote:
If this is the case, I whould suggest better solution. Only 3..5 cases
in a year are not enough to train the team enough and to increase the
situation awareness of the people. Isn't it better to make fossil to
fork randomly with probability, let say, 1:
On Sat, 12 Jan 2013 19:31:26 -0500
Richard Hipp wrote:
> I contend that this points up issues with your development process, not
> with Fossil. If your developers do not notice that a fork has occurred for
> days, then they are doing "heads down" programming. They are not
> maintaining situatio
on Jan 12, 2013, Richard Hipp wrote:
>
>
>On Sat, Jan 12, 2013 at 7:31 PM, Richard Hipp wrote:
>
>
>
>Loss of situational awareness is a leading cause of airplane crashes and
>medical
>errors.
>Here's another example of loss of situational awareness, which seems likely to
>result
>in an adver
On Sat, Jan 12, 2013 at 7:31 PM, Richard Hipp wrote:
> Loss of situational awareness is a leading cause of airplane crashes and
> medical errors.
Here's another example of loss of situational awareness, which seems likely
to result in an adverse outcome:
http://chronicleoutdoors.com/wp-conten
On Sat, Jan 12, 2013 at 6:41 PM, Matt Welland wrote:
> This is with regards to the problem described here:
>
>
> http://lists.fossil-scm.org:8080/pipermail/fossil-users/2008-February/60.html
>
> We are seeing on the order of 3-5 of these a year in our heaviest hit
> repos. While this may seem
18 matches
Mail list logo
