headers
Christian Boos | 1 Feb 2006 12:14
Picon

Switching p.e.c to 0.10dev?

Hi,

On our road to 0.10, it seems that we are half-way:

    * Support for database and version control backends as third-party
      plugins
    * Improved notification system
    * Advanced diff support
    * InterWiki support
    * todo:
          o MySQL database support
          o Use WSGI as web-frontend protocol
          o Hooks for spam filtering

I think that we now have good feeling about the stability of 0.9.3
(and probably of 0.9.4dev); it's maybe time to move forward.

As we did during the 0.9pre era, we should experiment our own stuff
before making a release, and I would suggest doing it incrementally:
As there are already 4 out 6(*) major items planned for 0.10 in trunk,
I think it makes sense to expose them to a wider audience.

Besides, the introduction of TracDiff features on p.e.c will ease
the code review process. Each "branch" Wiki page could contain
a diff link:

   diff:trunk <at> <last-base-rev-for-the-branch>//sandbox/≤branch>

That link would lead to a changeset page showing the exact set of
changes that the branch introduces.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Manuzhai | 1 Feb 2006 12:20
Picon

Re: Switching p.e.c to 0.10dev?

>           o MySQL database support

Is anyone working on that yet? If yes, where? I could test it/work on
it some more.

On-topic: switching p.e.c would be good, I guess, assuming that it
also uses Subversion 1.2. Otherwise there might be problems with the
#2611 thing.

Regards,

Manuzhai
Permalink | Reply | 2 comments |
headers
Christian Boos | 1 Feb 2006 12:30
Picon

Re: Switching p.e.c to 0.10dev?

Manuzhai wrote:
>>           o MySQL database support
>>     
>
> Is anyone working on that yet? If yes, where? I could test it/work on
> it some more.
http://projects.edgewall.com/trac/ticket/986

... which contains a patch that was supposed to work (not tried myself).
However, it was against 2659, which is a bit old by now, so it probably
needs to be fixed.

-- Christian
Permalink | Reply | 0 comments |
headers
Christian Boos | 1 Feb 2006 12:40
Picon

Re: Switching p.e.c to 0.10dev?

Manuzhai wrote:
> On-topic: switching p.e.c would be good, I guess, assuming that it
> also uses Subversion 1.2. Otherwise there might be problems with the
> #2611 thing.
>   

Yeah, at this point we can't really recommend 1.3.0, even if "for me it 
works" ...

I had no problem neither on Windows nor on Linux x64 with apache 2.0.55 and
mod_python 3.1.4 (prefork).

The latter is only in production since yesterday, so it *might* be 
possible that the
#2611 error surfaces for me too.

The only issue I noticed so far was #2038 (CSS intermittently not applied),
but then, only for one project out of 4 served from the same parent dir (?).

-- Christian
Permalink | Reply | 0 comments |
headers
Gary Thomas | 2 Feb 2006 00:14
Favicon

Re: Merge of TracDiff branch

On Thu, 2006-01-19 at 17:26 +0100, Christian Boos wrote:
> Christopher Lenz wrote:
> > Am 19.01.2006 um 08:05 schrieb Christian Boos:
> >> Christian Boos wrote:
> >>> Hi all,
> >>>
> >>> After some quiescent period, I revived the TracDiff branch, synced it
> >>> with the trunk and did some cleanups.
> >>> See http://projects.edgewall.com/trac/log/sandbox/trac-diff
> >>>
> >>> Now, I think that it's in a pretty good shape to make it into the 
> >>> trunk,
> >>> in order to get a wider exposure and do the final polish.
> >>>
> >>
> >> Ok, given the time this branch has been around, I guess people
> >> would have had plenty of time to review it if they wanted to.
> >>
> >> So if nobody speaks against it, I'll merge the branch later today.
> >
> > Yeah, just go ahead. Any remaining issues can be addressed in trunk.
> 
> Starting from trunk <at> 2813, the TracDiff features are looking good.
> Please try out the new shiny trunk!

Very nice.  One question though - why are there two radio buttons
for each possible revision to select?  I can't see that they have
any effect (I get the same changes regardless of which button was
pushed)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christian Boos | 2 Feb 2006 08:37
Picon

Re: Merge of TracDiff branch

Gary Thomas wrote:
> On Thu, 2006-01-19 at 17:26 +0100, Christian Boos wrote:
>> Starting from trunk <at> 2813, the TracDiff features are looking good.
>> Please try out the new shiny trunk!
>>     
>
> Very nice.  One question though - why are there two radio buttons
> for each possible revision to select?  I can't see that they have
> any effect (I get the same changes regardless of which button was
> pushed)
>   

The first radiobutton is for selecting the base (old revision),
the second radiobutton is for selecting the target (new revision).
If both are the same, that changeset is shown.
All of this is explained in the new TracRevisionLog wiki page,
please edit this one and clarify as you wish (my english is certainly
not optimal :) ).

I also wonder if by default, the base revision should not be the oldest
shown,
instead of the previous to last one, because viewing the ''Last Change''
is directly possible using the navigation link of the same name.

-- Christian
Permalink | Reply | 2 comments |
headers
Jørn A Hansen | 2 Feb 2006 10:46
Picon

Re: Merge of TracDiff branch

On 2/2/06, Christian Boos <cboos <at> neuf.fr> wrote:
> The first radiobutton is for selecting the base (old revision),
> the second radiobutton is for selecting the target (new revision).
> If both are the same, that changeset is shown.
> All of this is explained in the new TracRevisionLog wiki page,
> please edit this one and clarify as you wish (my english is certainly
> not optimal :) ).
>
> I also wonder if by default, the base revision should not be the oldest
> shown,
> instead of the previous to last one, because viewing the ''Last Change''
> is directly possible using the navigation link of the same name.
>

Good idea! I constantly fall into selecting the wrong order of the
radiobuttons and therefore have to reverse the order of the diff after
a few seconds of confusion when looking at the diff. As I understand
your suggestion with by default selecting the chronological order I
think we could get rid of having two buttons for each changeset. As
long as you keep the "Reverse Diff" option in the changeset view you
can still change the diff if chronological order wasn't what you
wanted.

A good intutive user interface is IMHO one that doesn't need any
explanation in the documentation - KISS :-)

----

Another topic:
Fooling around with the anydiff feature left me wondering why diffs
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alec Thomas | 2 Feb 2006 12:01

Re: Switching p.e.c to 0.10dev?

+1

I'm using trunk on TracHacks and it seems pretty good so far. The
InterTrac stuff is definitely very convenient too.

Alec

On Wed, Feb 01, 2006 at 12:14:09PM +0100, Christian Boos wrote:
> Hi,
> 
> On our road to 0.10, it seems that we are half-way:
> 
>    * Support for database and version control backends as third-party
>      plugins
>    * Improved notification system
>    * Advanced diff support
>    * InterWiki support
>    * todo:
>          o MySQL database support
>          o Use WSGI as web-frontend protocol
>          o Hooks for spam filtering
> 
> I think that we now have good feeling about the stability of 0.9.3
> (and probably of 0.9.4dev); it's maybe time to move forward.
> 
> As we did during the 0.9pre era, we should experiment our own stuff
> before making a release, and I would suggest doing it incrementally:
> As there are already 4 out 6(*) major items planned for 0.10 in trunk,
> I think it makes sense to expose them to a wider audience.
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Christian Boos | 2 Feb 2006 12:30
Picon

Re: Merge of TracDiff branch

Jørn A Hansen wrote:
> On 2/2/06, Christian Boos <cboos <at> neuf.fr> wrote:
>> ...
>> I also wonder if by default, the base revision should not be the oldest
>> shown,
>> instead of the previous to last one, because viewing the ''Last Change''
>> is directly possible using the navigation link of the same name.
>
> Good idea! I constantly fall into selecting the wrong order of the
> radiobuttons and therefore have to reverse the order of the diff after
> a few seconds of confusion when looking at the diff. As I understand
> your suggestion with by default selecting the chronological order I

Ah, no that was not exactly what I had in mind.

Let me take an example. If we are viewing the revision log of
a folder, showing the appropriate subset of range [1:444],
we have something like this:

( ) (o) ... rev 444
(o) ( ) ... rev 333
( ) ( ) ... rev 222
( ) ( ) ... rev 111

i.e. by default the old rev. is 333 and the new rev. is 444
(and that's the correct chronological order btw).

I was making the proposal to change the above to:

( ) (o) ... rev 444
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Boos | 2 Feb 2006 13:38
Picon

Re: Backporting "improved concurrency" to 2.0.x

Gerhard Häring wrote:
> Christian Boos wrote:
>> Thanks for the clarification.
>>
>> I updated Trac's wiki page about pysqlite with this info:
>>
>> http://projects.edgewall.com/trac/wiki/PySqlite
>>
>> Btw, you're welcome to point out any inaccuracy I could have written 
>> there :)
>
> No, I can agree with all that.
>
> Btw. the "improved concurrency" in 2.1 you mentioned in your 
> bugtracker  could easily be backported to 2.0. Is there a demand for 
> doing that?

Well, I think that 2.0.5 is "good enough" for the needs of Trac,
and I think it's best to push the 2.1.x release line forward.

I'm using [pysqlite 207] for some time now without any problem,
I wonder what has been the experience of other Trac developers
with the recent 2.1.x releases.

(I'm CC'ing this to Trac-Dev mailing list to gather feedback on that 
question)

-- Christian
Permalink | Reply | 0 comments |

Gmane