John Hendy <jw.he...@gmail.com> writes: > On Mon, Apr 1, 2013 at 5:01 PM, Nicolas Goaziou <n.goaz...@gmail.com> wrote:
>> You can already do so. IDs only have to be unique within the task >> siblings. > > True, one can name tasks identically as long as they have no identical > siblings... but the point was the since one can only specify the > lowest level of id (e.g. "T1" instead of "T.T1"), Org doesn't know how > to resolve them properly. AFAIK task_ids have to be globally unique if you want to use them for dependencies. > Task M1 ends up depending on both M.T1 (represented as !T1) /and/ > T.T1. It won't fail since both T.T1 and M.T1 exist, but the user has > no way to set a depends option to target the specific T1 they wanted. > Setting =:depends: !!T.T1= ignores the :depends: property entirely. The TaskJuggler exporter gives you 3 ways to express a dependency: 1. using ORDERED on the parent task 2. using "previous-sibling" 3. using a task_id of another task. This has to be a unique id, otherwise you end up depending all the other tasks that have this task_id. >> You don't have to name parents either. You only need to name tasks that >> will be used as a dependency. > > True, which is nice. But we're torn between: > - Letting Org name the parent whatever it wants, but then having to > figure out the org-generated parent id so we can do =:depends: > parent.subtask=, or > > - Specifically naming the parent to have control over the task_id, but > having to change it because we move it later (and then updating all > =:depends: parent.task_id= properties accordingly) > > And in either case, there's still no way to depend on a specific > =parent.task_id= combination. I don't understand this. Why do you need to name parents (or assign them a task_id)? As Nicolas says: all you have to do is to give the task you want to depend on a task_id. As an aside I thought you could also use plain ID to express dependencies. But from looking at the code this doesn't seem supported. I think the reason why yet another id (namely task_id) is used, is that this allows for short human readable ids where as the standard ID is generally generated by org mode and is cryptic and much longer. HTH Christian -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
