hi there,
reading through the documentation i thought some sentences
would be easier to read with some minor changes, and i also
removed end of line whitespace.
the other item from the subject concerns the future change
of '_FOSSIL_' to '.fos'. i am totally new on the list, so
i am not familiar
On Fri, Feb 3, 2012 at 5:36 PM, Leo Razoumov wrote:
> Hi Richard,
> I am afraid I found a bug in fossil scm version-1.21.
> Clone operation drops relevant commits and artifacts in a public
> branch causing loss of data.
>
> Please, find below a minimal case that demonstrates the bug on Linux
> (U
On Fri, Feb 3, 2012 at 5:36 PM, Leo Razoumov wrote:
> Hi Richard,
> I am afraid I found a bug in fossil scm version-1.21.
> Clone operation drops relevant commits and artifacts in a public
> branch causing loss of data.
>
> Please, find below a minimal case that demonstrates the bug on Linux
> (U
Hi Richard,
I am afraid I found a bug in fossil scm version-1.21.
Clone operation drops relevant commits and artifacts in a public
branch causing loss of data.
Please, find below a minimal case that demonstrates the bug on Linux
(Ubuntu-10.04).
For your convenience I wrapped the commands into a sh
I installed the "fossil" package from the Ubuntu repository, but it was
quite old, so I decided to update from source. However, I encountered a
couple issues when trying to generate the .deb, mainly, the official
package is named "fossil" and the makedeb.sh script creates "fossil-scm".
This creates
On Fri, Feb 3, 2012 at 14:41, Stephan Beal wrote:
> On Fri, Feb 3, 2012 at 8:23 PM, Leo Razoumov wrote:
>>
>> Now in the cloned repo fos2.fossil the old *public* branch
>> "exp-search" is not accesible anymore.
>
>
> When i try this exp-search is still visible under the branches list, but i
On Fri, Feb 3, 2012 at 8:23 PM, Leo Razoumov wrote:
> Now in the cloned repo fos2.fossil the old *public* branch
> "exp-search" is not accesible anymore.
>
When i try this exp-search is still visible under the branches list, but i
see no commits for it.
> For instance /artifact/0fd61
On Fri, Feb 03, 2012 at 08:33:41PM +0100, Stephan Beal wrote:
> How much work would it be to put together a proof-of-concept sbsdiff
> > colorizer?
>
>
> The new diffs can't reliably be colored using JS because of potential
> syntactic ambiguities. It would work "often" but not "always."
The s
On Fri, Feb 3, 2012 at 8:17 PM, Jan Danielsson
wrote:
> I wouldn't like that change very much. I think the way < and > are
> used now is very intuitive, and it creates a nice separator column with
>
i agree but having them in the middle makes it literally impossible to
reliably determine where/
Hi List,
I am using fossil version-1.21 on Linux Ubuntu-10.04 and am getting
weird corruption of the cloned repository.
If you would like to reproduce the problem you can download the repository from:
http://www.panix.com/~leor/fos/fos.fossil.bz2
Username: fossil
Password: fossil-scm
Here is wha
On 02/03/12 18:40, Stephan Beal wrote:
>>> I'm for color-coded. All of the reasons have already been listed in the
>>> thread.
>>
>> Same here.
>
> If not color coded, perhaps adding add/change/remove markers to the _start_
> of each line, since that would make JS-scripting the colorification
> re
I'd be happy with Stephan's suggestion, since it would satisfy both parties
with a little work on the colorizing side. I think the only additional
point is to have the or whatever surrounds the code to have a good
descriptive class we can latch on to with JS.
Tomek
On Fri, Feb 3, 2012 at 12:40 P
On Fri, Feb 3, 2012 at 6:33 PM, Weber, Martin S wrote:
> On 2012-02-03 12:31 , "Remigiusz Modrzejewski" wrote:
>
> >I'm for color-coded. All of the reasons have already been listed in the
> >thread.
>
> Same here.
>
If not color coded, perhaps adding add/change/remove markers to the _start_
of e
On 2012-02-03 12:31 , "Remigiusz Modrzejewski" wrote:
>I'm for color-coded. All of the reasons have already been listed in the
>thread.
Same here.
-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:808
On Feb 3, 2012, at 16:25 , Richard Hipp wrote:
> I find the "retro" side-by-side diff to be much more readable, which is why
> I am using it on the SQLite and Fossil websites, as well as on my desktop.
> And I've heard no complaints from users about the retro sbsdiffs on the
> website. But before
On Feb 1, 2012, at 15:18 , Chris Peachment wrote:
> I can't speak for MS-Windows or MacOS but Ubuntu Linux uses
> NTP by default.
So does OS X.
Kind regards,
Remigiusz Modrzejewski
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
ht
On Fri, Feb 3, 2012 at 11:18 AM, Matt Welland wrote:
> If I do:
>
> fossil rm some/file.txt
> rm some/file.txt
> ...do stuff...
> fossil update
>
> then some/file.txt is resurrected which is really really annoying when you
> just got your build to work and then because files that shouldn't be the
I think part of the original post was whether the documentation was
correct. i.e., it says uncommitted changes are retained. I would argue that
"fossil rm" is an uncommitted change, which should be retained. Either the
documentation is wrong or there is a bug w.r.t. "fossil rm".
As a work around,
On Fri, Feb 3, 2012 at 10:57 AM, Matt Welland wrote:
> On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh
> wrote:
>> On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote:
>> > If I do:
>> > fossil rm some/file.txt
>> > rm some/file.txt
>> fossil commit
> People often prefer to commit when their wo
On Fri, Feb 3, 2012 at 11:56 AM, Andreas Kupries
wrote:
> On 2/3/2012 7:25 AM, Richard Hipp wrote:
>
>> For some time now, the SQLite and Fossil websites have been running on the
>> "retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
>> simplified format for the side-by-side
On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh wrote:
> On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote:
>
> > If I do:
> >
> > fossil rm some/file.txt
> > rm some/file.txt
>
> fossil commit
>
People often prefer to commit when their work has reached some level of
completion or readiness a
On 2/3/2012 7:25 AM, Richard Hipp wrote:
For some time now, the SQLite and Fossil websites have been running on the
"retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for the side-by-side diffs that omits all of the colors and
decoration and provides plain
On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote:
> If I do:
>
> fossil rm some/file.txt
> rm some/file.txt
fossil commit
--
Dmitry Chestnykh
http://www.codingrobots.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists
On Fri, Feb 03, 2012 at 11:19:38AM -0500, Richard Hipp wrote:
> On Fri, Feb 3, 2012 at 10:47 AM, Jan Danielsson
> wrote:
>
> > - I haven't looked at the code lately, but does the web sbsdiff
> > support the width argument in some manner? For quite a few diffs I've
> > been looking at lately, sta
On 02/03/12 17:19, Richard Hipp wrote:
[---]
>> - I haven't looked at the code lately, but does the web sbsdiff
>> support the width argument in some manner? For quite a few diffs I've
>> been looking at lately, static 80 characters wide panes leaves a lot of
>> empty "wasted" space, due to short
On Wed, Feb 1, 2012 at 8:03 AM, Leo Razoumov wrote:
> On Wed, Feb 1, 2012 at 07:08, Richard Hipp wrote:
>> The clock according to the "D" card of the artifact.
>>
>> In other words, you can keep changing the value of a tag and the latest
>> version always wins.
>>
>> If two people change the valu
On Fri, Feb 3, 2012 at 10:47 AM, Jan Danielsson
wrote:
> - I haven't looked at the code lately, but does the web sbsdiff
> support the width argument in some manner? For quite a few diffs I've
> been looking at lately, static 80 characters wide panes leaves a lot of
> empty "wasted" space, due t
On 02/03/12 17:01, Tomek Kott wrote:
> My preference would be to keep the color SBS diffs, at least as a skin
> option or something, since I find it easier to notice changes and match
> them up. Maybe somewhere in the documentation on the header / skin, there
> could be css for a default coloring o
If I do:
fossil rm some/file.txt
rm some/file.txt
...do stuff...
fossil update
then some/file.txt is resurrected which is really really annoying when you
just got your build to work and then because files that shouldn't be there
suddenly reappear and things break.
I can see where might be some c
On Fri, Feb 3, 2012 at 8:25 AM, Richard Hipp wrote:
> For some time now, the SQLite and Fossil websites have been running on the
> "retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
> simplified format for the side-by-side diffs that omits all of the colors
> and decoration
My preference would be to keep the color SBS diffs, at least as a skin
option or something, since I find it easier to notice changes and match
them up. Maybe somewhere in the documentation on the header / skin, there
could be css for a default coloring of the sbs diffs that one could copy
into the
On 02/03/12 16:25, Richard Hipp wrote:
[---]
> Are there strong preferences one way or another?
There are two aspects I prefer with the original:
- I think color coding makes it easier to get a quick overview of
what's happened in a diff. ("I see a lot of red" is roughly
"optimizations", "I
On Fri, Feb 03, 2012 at 10:25:41AM -0500, Richard Hipp wrote:
> For some time now, the SQLite and Fossil websites have been running on the
> "retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
> simplified format for the side-by-side diffs that omits all of the colors
> and de
For some time now, the SQLite and Fossil websites have been running on the
"retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for the side-by-side diffs that omits all of the colors
and decoration and provides plain-text output - essentially the same output
On Fri, Feb 03, 2012 at 06:56:04AM -0500, Leo Razoumov wrote:
> Hi List,
> In one of my projects I am mostly working on one specific branch XYZ.
> But, being a novice fossil user, I mistakenly messed up the trunk.
> Now, how can i push only my branch XYZ without pushing whatever was
> entered into
Hi List,
In one of my projects I am mostly working on one specific branch XYZ.
But, being a novice fossil user, I mistakenly messed up the trunk.
Now, how can i push only my branch XYZ without pushing whatever was
entered into the trunk?
Is shunning my only option?
Are there plans to implement one-
36 matches
Mail list logo
