librelist archives

« back to archive

Rendering uncommitted files

Rendering uncommitted files

From:
Greg Ward
Date:
2012-12-11 @ 14:48
I've just noticed an apparent change from 0.10.1 to 0.11.1. With
0.10.1, blohg (in "runserver" mode) would render uncommitted changes,
as long as I remembered to "hg add" new files. With 0.11.1, I have to
commit changes before blohg will see them. ;-( This is rather annoying
when making microscopic CSS changes; I'm using MQ with frequent "hg
qrefresh" as a workaround.

Was this a deliberate change? Is it configurable back to the old
behaviour?

Thanks --

       Greg

Re: Rendering uncommitted files

From:
Greg Ward
Date:
2012-12-11 @ 15:01
On 11 December 2012, To blohg@librelist.com said:
> I've just noticed an apparent change from 0.10.1 to 0.11.1. With
> 0.10.1, blohg (in "runserver" mode) would render uncommitted changes,
> as long as I remembered to "hg add" new files. With 0.11.1, I have to
> commit changes before blohg will see them. ;-( This is rather annoying
> when making microscopic CSS changes; I'm using MQ with frequent "hg
> qrefresh" as a workaround.

Eeek: it's even worse than I thought: if I modify static/screen.css
and then commit (or qrefresh), then blohg starts returning a 404 for
that file. I have to restart the server -- ouch! IOW, for microscopic
CSS changes, I need to

  switch away from emacs window
  hg qrefresh
  switch away from that window
  ctrl-c and restart the "blohg runserver" process
  reload the page

Aieeeee!! Madness.

       Greg

Re: [blohg] Re: Rendering uncommitted files

From:
Rafael Martins
Date:
2012-12-12 @ 02:48
On Tue, Dec 11, 2012 at 1:01 PM, Greg Ward <greg@gerg.ca> wrote:

> On 11 December 2012, To blohg@librelist.com said:
> > I've just noticed an apparent change from 0.10.1 to 0.11.1. With
> > 0.10.1, blohg (in "runserver" mode) would render uncommitted changes,
> > as long as I remembered to "hg add" new files. With 0.11.1, I have to
> > commit changes before blohg will see them. ;-( This is rather annoying
> > when making microscopic CSS changes; I'm using MQ with frequent "hg
> > qrefresh" as a workaround.
>
> Eeek: it's even worse than I thought: if I modify static/screen.css
> and then commit (or qrefresh), then blohg starts returning a 404 for
> that file. I have to restart the server -- ouch! IOW, for microscopic
> CSS changes, I need to
>
>   switch away from emacs window
>   hg qrefresh
>   switch away from that window
>   ctrl-c and restart the "blohg runserver" process
>   reload the page
>
> Aieeeee!! Madness.
>
>        Greg
>

Hi Greg,

this isn't actually blohg's fault. Mercurial changes this behavior on its
API all the time :(

I noticed this problem happening with recent versions of mercurial, and
changed the way blohg handles uncommited changes. Blohg now evaluates the
change context on its own, without just rely on the mercurial api. The code
is on blohg's hg repository, but wasn't released yet.Tthis code is a major
rewrite of some bits, and will be the base of the 1.0 version, that I plan
to release in a few weeks.

The unreleased code is mostly safe to use, if you want to give it a try. I
use it for all my blogs.

Best Regards,

-- 
Rafael Goncalves Martins
http://rafaelmartins.eng.br/

Re: [blohg] Re: Rendering uncommitted files

From:
Matthew Turk
Date:
2012-12-12 @ 02:56
Hi Greg and Rafael,

While probably about the same as the qrefresh, I've had luck with "hg
commit --amend" for testing changes.

On Tue, Dec 11, 2012 at 9:48 PM, Rafael Martins
<rafael@rafaelmartins.eng.br> wrote:
> On Tue, Dec 11, 2012 at 1:01 PM, Greg Ward <greg@gerg.ca> wrote:
>>
>> On 11 December 2012, To blohg@librelist.com said:
>> > I've just noticed an apparent change from 0.10.1 to 0.11.1. With
>> > 0.10.1, blohg (in "runserver" mode) would render uncommitted changes,
>> > as long as I remembered to "hg add" new files. With 0.11.1, I have to
>> > commit changes before blohg will see them. ;-( This is rather annoying
>> > when making microscopic CSS changes; I'm using MQ with frequent "hg
>> > qrefresh" as a workaround.
>>
>> Eeek: it's even worse than I thought: if I modify static/screen.css
>> and then commit (or qrefresh), then blohg starts returning a 404 for
>> that file. I have to restart the server -- ouch! IOW, for microscopic
>> CSS changes, I need to
>>
>>   switch away from emacs window
>>   hg qrefresh
>>   switch away from that window
>>   ctrl-c and restart the "blohg runserver" process
>>   reload the page
>>
>> Aieeeee!! Madness.
>>
>>        Greg
>
>
> Hi Greg,
>
> this isn't actually blohg's fault. Mercurial changes this behavior on its
> API all the time :(
>
> I noticed this problem happening with recent versions of mercurial, and
> changed the way blohg handles uncommited changes. Blohg now evaluates the
> change context on its own, without just rely on the mercurial api. The code
> is on blohg's hg repository, but wasn't released yet.Tthis code is a major
> rewrite of some bits, and will be the base of the 1.0 version, that I plan
> to release in a few weeks.

Does this use the hglib interface?

>
> The unreleased code is mostly safe to use, if you want to give it a try. I
> use it for all my blogs.
>
> Best Regards,
>
> --
> Rafael Goncalves Martins
> http://rafaelmartins.eng.br/


-Matt

Re: [blohg] Re: Rendering uncommitted files

From:
Rafael Martins
Date:
2012-12-12 @ 04:29
On Wed, Dec 12, 2012 at 12:56 AM, Matthew Turk <matthewturk@gmail.com> wrote:
>
> > I noticed this problem happening with recent versions of mercurial, and
> > changed the way blohg handles uncommited changes. Blohg now evaluates the
> > change context on its own, without just rely on the mercurial api. The code
> > is on blohg's hg repository, but wasn't released yet.Tthis code is a major
> > rewrite of some bits, and will be the base of the 1.0 version, that I plan
> > to release in a few weeks.
>
>
> Does this use the hglib interface?

No, blohg uses the Mercurial python API directly. It was created
before hglib. I have interest on hglib though, basically to try
relicensing blohg to BSD, but don't know if it is worth the hassle.

--
Rafael Goncalves Martins
http://rafaelmartins.eng.br/