Re: cmd manager transactions

[Lee Baylis <lee leebaylis co uk>]

Maurice van der Pot wrote on 25/12/8 at 10:47:
> I sent some comments on the patch earlier.
I don't think I ever got these comments, and they're not in the 
planner-dev-list archives. Sorry to be a pain, I don't suppose you have 
copy-to-self?

> I have also noticed some
> indentation inconsistencies in the patches. Do you have your indentation
> set to tabs? vim & emacs should be able to use the mode lines at the
> top. 
I'm using emacs and the mode lines seem to be working OK -- I realised 
there might have been some indentation inconsistencies in the middle of 
lines (in order to pull arguments for functions in line, for example) 
because of some late changes I made, but I thought indents at the 
beginning of lines should have all been fine. I will keep an eye on it 
in future patches.

> If you could also send the changes to multiple files in one patch,
> that would be easier for me.
>   
OK. I am currently moving all my patches from svn to git to make sure 
nothing has changed meanwhile, but when done I will send a single file.
> I was wondering, how do you plan to proceed from the
> overallocation-prohibited version? What kind of user interaction with
> the GUI would we eventually have?
>
>   
The next step I took is to have a simple algorithm which fires when an 
overallocation is detected, and alters the allocations which clash based 
on task priority, in order to bring allocation to max_units. At the 
moment none of it is settable in the GUI and it is only done at compile 
time.

However, I envisage eventually having a property settable on the project 
so that a user can pick which algorithm they want for the entire project 
when overallocation occurs. Options might be

- ignore (planner's current behaviour)

- prohibit (as per my first proof of concept)

- reallocate conflicts based on priority (as per my second proof of concept)

- reschedule conflicts based on priority (I don't have the code for this 
yet but I have a good idea how the algorithm would work)

- other algorithms (libRCPS maybe)

- Ask me every time (produces a dialog with the options above when 
overallocation occurs)
> Now I was thinking on how to handle integration of your (future) changes
> into planner. There are disadvantages to each approach I can come up
> with:
>
> committing to trunk:
> - if it takes a long time to finish, it could be in the way for
>   in-between releases
> - I wouldn't like to litter the code with ifdefs, especially in cases
>   where you would rewrite large pieces of old code
>
> committing to a branch:
> - subversion < 1.5 doesn't have merge tracking. I haven't been able to
>   figure out if Gnome's running 1.5 yet.
>
> distributed version control:
> - Gnome doesn't offer it
> - I've never worked with it (though I've always wanted to try Git) =)
>
>   
Looks like moving to git has got around this problem (or will have when 
I migrate my existing patches)

Thanks,
lee
> Regards,
> Maurice.
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Planner-dev-list mailing list
> Planner-dev-list gnome org
> http://mail.gnome.org/mailman/listinfo/planner-dev-list
>