On 11-05-20 7:49 PM, Mark Lawrence wrote:
> Hi Jeff,
> 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.
Thanks, in hindsight I could have clarified the request for help a
little more lol.
Any and all feedback on TicGit-ng and the storage format document are
appreciated, but specifically the thinking behind the request was to get
another pair of eyes (unfamiliar with TicGit-ng) looking at the
document, ideally reviewing it from the perspective of someone who would
be planning to read/write the storage format directly - though yes, I
realize that's highly unlikely at such an early stage of development.
I wasn't sure I'd even get a response, so your email made my day!
>
> 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?)
I don't think Github 'came up with' the idea, I just kind of picked it
up reading other pages on the web which link possibly-foreign terms or
usages to more information on them. Github certainly does facilitate
such linking though, you can link to any line in any document in your
repo on Github. Markdown[1] deseveres some credit too, its pretty neat
and easy to work with.
> What is
> missing is the rationale behind the choice of format(s).
I wish I really wish I knew that rational myself, but as I'm not the
original developer and his track record of responding to communications
is attrocious (Took 2 years to get 1 email response), I'm not privy to
that information. I'm having to reverse engineer it as I go.
>
> I think the storage format itself has a number of problems:
>
> - 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?
>
> - Long titles could result in filenames that are too long for a
> shell to handle ("ls $LONGFILE: File name too long")
I hadn't considered this, but it seems like something easily remedied by
truncating the filename to an acceptable length in situations where it
is too long to use as a filename like that. Because the actual title is
stored in the TITLE file, this shouldn't result in any lost information.
>
> - Non-ascii (unicode) titles can create invalid filenames on some
> systems?
This should already be taken care of by the way filenames are cleaned[3]
before they are used to create the directory name. Only alphanumeric
values are permitted in the filename, everything else is turned into '-'.
>
> - Changes to an issue title are not reflected in the storage - so
> why use human readable filenames at all?
Well, they *are* reflected in storage (in the TITLE) file, but I see
your point, why bother using human readable filenames if changes aren't
reflected in said filenames.
I think this has to do with the fact that originally, TicGit *did* store
the title in the filename without a TITLE file but at some point in the
past this behavior was changed to accomodate non-alphanumeric titles.
So, the human readable filenames are arguably just legacy support. I
like that they're human readable though, ticket titles don't change very
frequently and when they do we keep track of the new title, and you
don't have to go into the storage format to make changes anyway - the
human readable filenames I suppose just help with debugging when you
have to go wandering into the ticgit branch or ~/.ticgit directory yourself.
>
> - What happens if there are multiple ASSIGNED_* files?
Excellent question...
At present, I assume it simply uses the value from the file that it read
in last. This needs more attention on my part. Thanks for bringing it
up. Same with STATE_* 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?
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
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.
>
> 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.
:D
> 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.
Thanks a LOT for your feedback, it is truely valued.
Cheers,
Jeff Welling.
[1] http://daringfireball.net/projects/markdown/syntax
[2] http://progit.org/book/ch9-2.html
[3]
https://github.com/jeffWelling/ticgit/blob/280e4bbb01bc358ebcaf2a472ca75e2265736807/lib/ticgit-ng/ticket.rb#L125
_______________________________________________
dist-bugs mailing list
[email protected]
http://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs
