Alec Thomas | 2 May 06:05 2006

Re: Implementing ticket dependencies

On Sun, Apr 23, 2006 at 11:13:27AM -0400, Sergey Lipnevich wrote:
> This is awesome! Can the combo of find_duplicates method and
> Similarity class be a plug-in :-)?
> Thank you!

Okay, implemented in r3260

--

-- 
Evolution: Taking care of those too stupid to take care of themselves.
Emmanuel Blot | 2 May 16:25 2006
Picon

P.E.C updates

Hi,

Is there a way to get notified when p.e.c. is updated with the trunk ?
I think it would be useful to post a notification (to trac-dev or
through a long-lasting ticket) to other developers, with the actual
revision that p.e.c. is running.

Thanks,
Manu
Christian Boos | 3 May 09:30 2006
Picon

Re: P.E.C updates

Emmanuel Blot wrote:
> Hi,
>
> Is there a way to get notified when p.e.c. is updated with the trunk ?
> I think it would be useful to post a notification (to trac-dev or
> through a long-lasting ticket) to other developers, with the actual
> revision that p.e.c. is running.

+1

... and a more "community friendly" way to run the Trac site would be
appreciated as well. For instance, my queries to upgrade to 0.10dev
in January have been ignored, though it would have been good to have
a check point at that time (before the unicode merge), my repeated
queries to add some intertrac links have been ignored as well, etc.

-- Christian
Christian Boos | 3 May 12:25 2006
Picon

vc-refactoring and caching

Hi all,

I think I've come up with a better way to manage the vc cache.

As you know, we currently only store the information directly
needed for the TracChangeset component.
The TracBrowser part still needs to have direct access to the
repository and make use of the cache.
The proposed change would make it possible to implement the
`get_node()/get_entries()` methods in a generic an efficient way.

More details here:

http://projects.edgewall.com/trac/wiki/VcRefactoring#SupportforBigRepositories

I have the feeling that this cached information can be used for
other needs as well:
 * next/prev revision for a given path
 * implement efficiently the revision graph view (#1445)

Also, I'd like to get some feedback about the possible choices
we have for handling multiple repositories:

http://projects.edgewall.com/trac/wiki/VcRefactoring#SupportforMultipleRepositories

Thanks for your time,

-- Christian
Philip Bergen | 3 May 15:30 2006
Picon

Milestones in tickets disappear

Hi,

When a milestone is closed it no longer appears as a choice in tickets. 
Makes sense for tickets already assigned to that milestone. If you go in 
and close released tickets they will now quietly lose their milestone 
assignment. This -from my point of view- is a bug.

Is there a simple way to hack into the code that a ticket milestone 
choice should range open milestones + current milestone?

/Philip
Matthew Good | 3 May 15:56 2006
Picon

Re: Milestones in tickets disappear

On Wed, 2006-05-03 at 13:30 +0000, Philip Bergen wrote:
> When a milestone is closed it no longer appears as a choice in tickets. 
> Makes sense for tickets already assigned to that milestone. If you go in 
> and close released tickets they will now quietly lose their milestone 
> assignment. This -from my point of view- is a bug.

Closed milestones are only unavailable when creating new tickets.  For
existing tickets the full list of milestones is available.  On the Trac
site it's not uncommon to realize that certain tickets were resolved
after a release, so they may be assigned to a closed milestone.  If you
can reproduce the problem you mentioned above please open a ticket
listing the steps you took.

--

-- 
Matthew Good <trac <at> matt-good.net>
Philip Bergen | 3 May 16:39 2006
Picon

Re: Milestones in tickets disappear

Hi,
It is very consistent on sandbox/workflow. I do have a small number of 
local changes, but that should only affect what statuses are considered 
'closed' in milestones.
Any ticket assigned to a milestone that is closed will leave 
'Milestone:' selecting an empty element in the combobox when the ticket 
is edited.
At the top of the ticket the milestone reads 'Release 5.6' and in the 
milestone choice at the bottom only open milestones may be chosen. Any 
modification to the ticket will overwrite the milestone with an empty 
string.

/Philip

Matthew Good wrote:

>On Wed, 2006-05-03 at 13:30 +0000, Philip Bergen wrote:
>  
>
>>When a milestone is closed it no longer appears as a choice in tickets. 
>>Makes sense for tickets already assigned to that milestone. If you go in 
>>and close released tickets they will now quietly lose their milestone 
>>assignment. This -from my point of view- is a bug.
>>    
>>
>
>Closed milestones are only unavailable when creating new tickets.  For
>existing tickets the full list of milestones is available.  On the Trac
>site it's not uncommon to realize that certain tickets were resolved
>after a release, so they may be assigned to a closed milestone.  If you
(Continue reading)

Matthew Good | 3 May 17:28 2006
Picon

Re: Milestones in tickets disappear

On Wed, 2006-05-03 at 14:39 +0000, Philip Bergen wrote:
> It is very consistent on sandbox/workflow. I do have a small number of 
> local changes, but that should only affect what statuses are considered 
> 'closed' in milestones.
> Any ticket assigned to a milestone that is closed will leave 
> 'Milestone:' selecting an empty element in the combobox when the ticket 
> is edited.
> At the top of the ticket the milestone reads 'Release 5.6' and in the 
> milestone choice at the bottom only open milestones may be chosen. Any 
> modification to the ticket will overwrite the milestone with an empty 
> string.

The sandbox branches are experimental and will almost certainly contain
bugs not found in the trunk or stable releases, so be absolutely certain
to mention when you're using a sandbox branch to avoid confusion.

Alec is working on the Workflow sandbox and may be able to help, but if
you'd like to provide a patch I'm sure he'd appreciate it :)

--

-- 
Matthew Good <trac <at> matt-good.net>
Jonas Borgström | 3 May 19:29 2006

Re: P.E.C updates

Christian Boos wrote:
> Emmanuel Blot wrote:
>> Hi,
>>
>> Is there a way to get notified when p.e.c. is updated with the trunk ?
>> I think it would be useful to post a notification (to trac-dev or
>> through a long-lasting ticket) to other developers, with the actual
>> revision that p.e.c. is running.
> 
> +1
> 
> ... and a more "community friendly" way to run the Trac site would be
> appreciated as well. For instance, my queries to upgrade to 0.10dev
> in January have been ignored, though it would have been good to have
> a check point at that time (before the unicode merge), my repeated
> queries to add some intertrac links have been ignored as well, etc.

Since projects.edgewall.com needs to be functioning at all times the
upgrade policy has always been to track the latest stable branch and
only switch to trunk when we're close to a new stable release.
So once we've made switch to trunk we have to stay there until a new
stable branch has been cut. This is why switching p.e.c to trunk just
for a "check point" is not such a good idea. But I still never heard
your query about upgrading to trunk in January...

Which InterTrac aliases are you interested in?

Regarding the revision p.e.c is running, a good solution would be to
hack the about page to show the revision next to the version number.
Is that a good enough solution?
(Continue reading)

Emmanuel Blot | 3 May 19:31 2006
Picon

Re: P.E.C updates

> Regarding the revision p.e.c is running, a good solution would be to
> hack the about page to show the revision next to the version number.
> Is that a good enough solution?

This is ok for me.
Maybe this info may only appear if you are logged in, if security
concerns matter.

Thanks,
Manu

Gmane