2014-04-03 3:53 GMT+02:00 Andy Bradford :
> It looks like a bug to me. For example, line 45 seems to correctly show
> the purple #define on the left being replaced with a purple space on the
> right. But the tail end shows a red G at the end of the macro being
> replaced with nothing on the
Thus said Andy Goth on Wed, 02 Apr 2014 21:37:35 -0500:
> When the UUID is abbreviated to one or two characters, the ambiguous
> artifact page is bypassed, and it always seems to link to a ticket.
This explains why it always links to a ticket once you get to ``4e'' and
just ``4'' for the UUID:
Andy Goth wrote:
>
> I'm curious how a script could make use of [fossil extras] without the
> benefit of the --showfile option.
>
The --showfile option is processed by the [fossil all] command, not the
[fossil extras] command, which basically explains the underlying issue...
The [fossil extras]
Thus said Andy Goth on Wed, 02 Apr 2014 21:37:35 -0500:
> When the UUID is abbreviated to three characters, no artifact is
> found.
>
> When the UUID is abbreviated to one or two characters, the ambiguous
> artifact page is bypassed, and it always seems to link to a ticket.
This explains
When the UUID is abbreviated to three characters, no artifact is found.
When the UUID is abbreviated to one or two characters, the ambiguous
artifact page is bypassed, and it always seems to link to a ticket.
Good (shows two ticket changes):
http://www.fossil-scm.org/index.html/info/4e684
Goo
On 4/2/2014 9:00 PM, Andy Bradford wrote:
Thus said Andy Goth on Wed, 02 Apr 2014 20:52:04 -0500:
For unified and side-by-side diffs, I'd like the option to show the
entire file in addition to the current behavior of showing only a
limited context surrounding the changes.
Maybe I misun
Thus said Andy Goth on Wed, 02 Apr 2014 20:52:04 -0500:
> For unified and side-by-side diffs, I'd like the option to show the
> entire file in addition to the current behavior of showing only a
> limited context surrounding the changes.
Maybe I misunderstand your intention, but while view
On 4/2/2014 8:53 PM, Andy Bradford wrote:
It looks like a bug to me. For example, line 45
If you think that's bad, check (new) lines 105 through 108 and 112.
Only when ignoring whitespace, they have non-changes highlighted as
additions.
--
Andy Goth |
Thus said Andy Goth on Wed, 02 Apr 2014 18:05:24 -0500:
> The highlighting in most lines of this diff is confusing, and I don't
> think I can explain it fully. You'll just have to see for yourself.
> Indeed, there are numerous cases of something being highlighted as a
> change even though it
For unified and side-by-side diffs, I'd like the option to show the
entire file in addition to the current behavior of showing only a
limited context surrounding the changes. This can be exposed in the
same way as the whitespace option.
--
Andy Goth |
1. With the potentially wider screen offered by a web browser, I don't
see a reason why the user and line number can't both be displayed. Can
annotate and blame be combined somehow? Perhaps offer magic JavaScript
checkboxes to show/hide the various columns (commit, date, time [not
currently s
On 4/2/2014 7:47 PM, Joe Mistachkin wrote:
Andy Goth wrote:
I prefer the behavior of [fossil all changes]. By default it prints
the names of both the repositories and directories with changes, plus
doesn't print anything for directories with no changes.
I would prefer to be consistent as well
Andy Goth wrote:
>
> Without the --showfile option, [fossil all extras] just prints filenames
> relative to the directories in which the repositories were opened. It's
> anyone's guess which files go with which directories and which
> repositories. Additionally, --showfile prints the names o
Without the --showfile option, [fossil all extras] just prints filenames
relative to the directories in which the repositories were opened. It's
anyone's guess which files go with which directories and which
repositories. Additionally, --showfile prints the names of all
directories, not just
On 4/2/2014 5:57 PM, David Given wrote:
I recently migrated the repo from CVS to hg (sorry). This is the first
checkin:
https://sourceforge.net/p/tack/tack/ci/4bea19e501ed
That's actually *older* than CVS! It may even be older than RCS...
RCS dates back to 1982, two years before your initial
http://www.fossil-scm.org/index.html/fdiff?v1=ff3ce7fdb65c5501&v2=f897c6fc3888f9ea&sbs=1&w
The highlighting in most lines of this diff is confusing, and I don't
think I can explain it fully. You'll just have to see for yourself.
Indeed, there are numerous cases of something being highlighted a
On 4/2/14, 7:21 PM, Stephan Beal wrote:
[...]
> i didn't even know RCS could do branches. My RCS phase was short-lived
> before "upgrading" to CVS.
As a totally off-topic comment, one of my other hats is the part-time
maintainer of the Amsterdam Compiler Kit, the ancient compiler toolchain
written
On Tue, Apr 01, 2014 at 10:24:44PM -0500, Andy Goth wrote:
> The attached script imports an RCS repository into Fossil. It
> doesn't support branching nor symbolic names, and it has a few
> peculiarities designed to accommodate the RCS repository I just
> processed.
You might consider
http://www.
On Wed, Apr 2, 2014 at 9:22 PM, Andy Goth wrote:
> reveals we already have an andybradford but also many first-name-only
> users such as bob and eric and erik.
>
> So "andy" should be okay.
i'll give Andy Bradford a while to veto that or not before setting you up,
just to avoid any potential fu
On 4/2/2014 2:22 PM, Andy Goth wrote:
On 4/2/2014 2:03 PM, Stephan Beal wrote:
please send me your desired user name off-list and i'll get you set up
after confirmation from DRH.
I prefer "andy", though obviously that can cause confusion.
Damnit, I really meant to reply to you off-list. I a
On 4/2/2014 2:03 PM, Stephan Beal wrote:
please send me your desired user name off-list and i'll get you set up
after confirmation from DRH.
I prefer "andy", though obviously that can cause confusion.
SELECT DISTINCT user FROM event ORDER BY user
reveals we already have an andybradford but al
On 4/2/2014 2:03 PM, Stephan Beal wrote:
On Wed, Apr 2, 2014 at 8:57 PM, Andy Goth wrote:
We have an old RCS repository with lots of useful data in it.
Okay, a love for your data is healthy and normal ;).
I have no love for this data, and no one else does either, but we're
stuck with it. Fo
On Wed, Apr 2, 2014 at 3:03 PM, Stephan Beal wrote:
> On Wed, Apr 2, 2014 at 8:57 PM, Andy Goth wrote:
>
>> I've actually already signed that form, once for Fossil and once for
>> SQLite, and I gave them to drh in person at the 18th Annual Tcl Conference
>> (2011) in Manassas. However, this was
On Wed, Apr 2, 2014 at 2:57 PM, Andy Goth wrote:
> On 4/2/2014 1:21 PM, Stephan Beal wrote:
>
> On Wed, Apr 2, 2014 at 8:14 PM, Andy Goth wrote:
>>
>>> These scripts I've written, is there a public place to collect,
>>> advertise, and improve them?
>>>
>>
>> You've done the first part ;). If you
On Wed, Apr 2, 2014 at 8:57 PM, Andy Goth wrote:
> I've actually already signed that form, once for Fossil and once for
> SQLite, and I gave them to drh in person at the 18th Annual Tcl Conference
> (2011) in Manassas. However, this was immediately after the AlcoBOF, so I
> wouldn't be too surpr
On 4/2/2014 1:21 PM, Stephan Beal wrote:
On Wed, Apr 2, 2014 at 8:14 PM, Andy Goth wrote:
These scripts I've written, is there a public place to collect,
advertise, and improve them?
You've done the first part ;). If you are up for this:
http://fossil-scm.org/index.html/doc/trunk/www/copyrigh
On Wed, Apr 2, 2014 at 2:21 PM, Stephan Beal wrote:
> On Wed, Apr 2, 2014 at 8:14 PM, Andy Goth wrote:
>
>> These scripts I've written, is there a public place to collect,
>> advertise, and improve them?
>
>
> You've done the first part ;). If you are up for this:
>
> http://fossil-scm.org/index
On Wed, Apr 2, 2014 at 8:14 PM, Andy Goth wrote:
> These scripts I've written, is there a public place to collect,
> advertise, and improve them?
You've done the first part ;). If you are up for this:
http://fossil-scm.org/index.html/doc/trunk/www/copyright-release.html
then you can get commi
>> This script imports from RCS, and the one
>> I wrote before imports from Fossil (haha, that's really what it does).
>
>
> LOL! You must really love RCS!
>
>> They're not fully featured; for instance neither does branches. But
>> they meet my minimum requirements.
>
>
> i didn't even know RCS co
Do you want dev access to
https://core.tcl.tk/akupries/fossil2git/index
?
I should rename that to 'fx' (Fossil eXtended).
On Wed, Apr 2, 2014 at 11:14 AM, Andy Goth wrote:
> On 4/2/2014 12:56 PM, Stephan Beal wrote:
>>
>> On Wed, Apr 2, 2014 at 5:24 AM, Andy Goth wrote:
>>>
>>> The attach
On 4/2/2014 12:56 PM, Stephan Beal wrote:
On Wed, Apr 2, 2014 at 5:24 AM, Andy Goth wrote:
The attached script imports an RCS repository into Fossil.
i'm thrilled to see someone create a tool for exporting RCS "repos" to
fossil :).
These scripts I've written, is there a public place to colle
On Wed, Apr 2, 2014 at 10:42 AM, Andy Goth wrote:
> On 4/1/2014 10:24 PM, Andy Goth wrote:
> For me, the slowest part of the import was by far the RCS checkouts.
> Optimizing this would require writing a custom RCS checkout implementation
> that doesn't have to start from scratch for each revisio
On Wed, Apr 2, 2014 at 12:29 AM, Joe Mistachkin wrote:
> Thanks for the report, fixed now on trunk.
>
As well as in the "unofficial standalone th1 lib fork."
Thanks!
http://fossil.wanderinghorse.net/repos/th1-sgb/index.cgi/wiki/th1-sgb
--
- stephan beal
http://wanderinghorse.net/home/step
On Wed, Apr 2, 2014 at 5:24 AM, Andy Goth wrote:
> The attached script imports an RCS repository into Fossil. It doesn't
> support branching nor symbolic names, and it has a few peculiarities
> designed to accommodate the RCS repository I just processed.
LOL! When i saw the subject line i thou
On 4/1/2014 10:24 PM, Andy Goth wrote:
The attached script imports an RCS repository into Fossil. It doesn't
support branching nor symbolic names, and it has a few peculiarities
designed to accommodate the RCS repository I just processed.
I should mention that this script opens the repository
On Wed, Apr 2, 2014 at 2:56 AM, Jan Nijtmans wrote:
> 2014-04-02 2:24 GMT+02:00 Joseph Prostko :
>> Below is a patch via `fossil diff` to detect getloadavg() which allows
>> Fossil to build cleanly on Haiku (and potentially other systems that
>> would happen not to have getloadavg() available.
>
>
36 matches
Mail list logo
