On Sun May 22, 2011 at 12:08:19AM -0400, Jeff W wrote:
> >
> > - All issues in a single directory doesn't scale very well.
> I think this is something I can remedy by basically doing what git
> does[2], taking the first 2 characters of the name and making it a
> directory, and using the remaining string as the filename within said
> directory. I think that should scale well, up to a point.
> Thoughts?
That scales with Git (and I believe Exim uses the same idea) as
filenames are based on a hashing function, which nicely distributes the
names across the hexidecimal character set (0-9a-f). In contrast, every
TicGit-ng issue for the next 50 million seconds (roughly) is going to
begin with '13' (if you use the epoch) or will be distributed according
to the way people start their ticket names, which is no guarantee of
scalability either.
> > - COMMENT_ files have an epoch in the filename, but time is taken
> > from a magic string in the file. Something of an unecessary
> > duplication there?
> I'll have to look into this 'magic string' that your speaking of.
> Oh, unless you mean the extremely recent change that I made which keeps
> track of the time of the most recent change by using an
> "\n#Updated_at=..." tag in the comment itself, in which case the tag in
That's what I meant.
> the comment keeps track of the most recent time the comment was updated
> at, whereas the epoch in the filename keeps track of when the ticket
> itself was made. I think it's important to keep track of both of these
> pieces of information, and using strictly the git log would be a burden
> I think.
The duplication is still there:
1305772178_ti-show-should-show-year-on-comments_141
├── [email protected]
├── [email protected]
├── [email protected]
The first epoch (in the directory) tells you when the ticket was
created. The epoch in each COMMENT_ file tells you when the ticket was
updated. The \n#Updated_at= string duplicates the COMMENT_<epoch>?
> > If you want TicGit-ng
> > to become *the* distributed issue system I think it still has a way to
> > go.
> I'm very much open to suggestions and discussion about how to improve
> Ticgit, any features you think should be added, etc.
Features should be driven by your users and as I am not one I won't
request any. As far as improvements go I think there are many that
could be made but I think that focusing on one particular tool is
a premature discussion in terms of relevance to this mailing list.
What would be nice for this list to see (and discuss) would be how
ticgit-ng handles the use cases described at:
http://dist-bugs.branchable.com/use-cases/
In other words, I'm searching for answers as to how should the ideal
Distributed Bug Tracker work, and how does TicGit-ng measure up against
the ideal? I don't think we have the ideal case documented anywhere
yet.
Mark.
--
Mark Lawrence
_______________________________________________
dist-bugs mailing list
[email protected]
http://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs
