first experiences with DITrack

[Ivan Glushkov]

Hi.

> Later I realized there is another feature I'd like to have, namely default
> filtering.
good idea! :)
> >> The structure of this is
> >>
> >> ~/projects/Proj1/trunk/.....
> >> ~/projects/Proj1/branch/branch1/.....
> >> ~/projects/Proj1/branch/branch2/.....
>  >>
> >> The logical place for DITrack data is at ~/projects/Proj1/issues,
>
> > Can you take a look at i#147
> > (http://issues.ditrack.org/index.cgi?issue=147) and see if that would
> > address your problem?
>
> It doesn't at this moment. SVN working copies start at the "....."
> sub-directories in my case, so there are no SVN properties in ~/projects/Proj1
> to query.
>
> One solution would be to move the project in the repository to make it work as
> proposed. Whether that is a feasible solution for all cases is an open
> question to me.
>
>
> As a possible alternative direction, what about having a set of path prefixes
> to relate ditrack roots to pwd?
>
> For example, a ~/.ditrackrc file with lines like
>
> [roots]
> ~/projects/Proj1/issues = ~/projects/Proj1
>
> (I am using the ConfigParser syntax of section "[roots]" with key/value pairs
> seperated with a '=' character)
>
>
> This configuration states that the ditrack "~/projects/Proj1/issues" working
> copy should be used whenever my pwd starts with "~/projects/Proj1".
>
>
>
> Another solution would be the ability to specify a user-defined filename
> instead of a fixed svn property. However also in that case, you'd need a
> ~/.ditrackrc resource file.

I also suppose that we should have some .ditrackrc file. It'll help us a lot
(and, of course, without it a default mechanism should be used).
Also .ditrackrc could be used to solve the i#147 (as described above,
for example).

Ivan.