Hi Jeff,
On Thu May 19, 2011 at 01:17:53AM -0400, Jeff W wrote:
> As you probably already know from my last thread, I'm working on
> syncing tickets between bug trackers. In the process, I've written
> this page[0] which I hope explains TicGit-ng's storage format enough
> for other people to understand how it works, and I was wondering if I
> could get some feedback on it when anyone has some spare time.
A call to help should never go unanswered! (You never know when you are
going to make your own call... :-) It is not clear to me if you were
asking for feedback on the document itself, or the TicGit-ng storage
format, so I quickly talk about both. Please take these comments with a
grain of salt however as I haven't used TicGit-ng nor looked closely at
the code.
As far as the document goes I think it is pretty clear in documenting
the on-file format. I like the links to the actual code. In fact that
is a fantastic idea. (Is that something GitHub came up with?) What is
missing is the rationale behind the choice of format(s).
I think the storage format itself has a number of problems:
- All issues in a single directory doesn't scale very well.
- Long titles could result in filenames that are too long for a
shell to handle ("ls $LONGFILE: File name too long")
- Non-ascii (unicode) titles can create invalid filenames on some
systems?
- Changes to an issue title are not reflected in the storage - so
why use human readable filenames at all?
- What happens if there are multiple ASSIGNED_* files?
- 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?
- What happens if multiple STATE_* files exist?
If your goal was merely to document enough detail for other issue
tracking systems to be able to read (import) a TicGit-ng repo I think
you have succeeded. If you wanted to trigger some discussion of the
TicGit-ng format I think you have also succeeded. If you want TicGit-ng
to become *the* distributed issue system I think it still has a way to
go.
Regards,
Mark.
--
Mark Lawrence
_______________________________________________
dist-bugs mailing list
[email protected]
http://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs
