Roundup is supremely flexible.  

What would make it even more so is if we could store our issues (and
everything else) as files and directories which could then be version
controlled. To support distributed version control, it would help if
roundup objects could have non-sequential names, ie. derived from some
sort of hash.  A good example of this in action is the bugs-everywhere
tracker:
 - http://bugseverywhere.org/be/show/HomePage

What would be awesome if there could be something with the generality of
roundup but the DVCS-friendliness of bugs-everywhere, because it is
extremely reassuring to be able to consult and update one's bug tracker
offline.

At first, in msg3930 I thought this was what issue2550547 was all about,
but after reading
http://www.scribd.com/doc/16508428/Google-Summer-of-Code-2009-Roundup-Improvements
I see that this was solving a slightly different problem (making roundup
notice changes reported via VCS).

This would require a major rewrite of roundup. Unless you want to
undertake that, I don't see any chance of it occurring.

So I am going to close this as rejected.

You may be interested in http://fossil-scm.org/ which is a DVCS, simple
distributed bug tracker and distributed wiki all rolled into one.

I take back what I said about a major rewrite. Everything you want to do I think can
be done under the hyperdb level that roundup uses to access the database/filesystem.

This may be doable using the dbm backend, or creating a new db backend. There
doesn't seem to be any requirement in the code for sequential numbering of objects
that are stored in the database or on the filesystem (messages and attached files).

Internally object id's are type string. But I can't guarantee that there
aren't conversions to integer in some places. The use of strings for ids does cause
the code to be slower than if we had used integers originally. But I don't think
the code is going to be rewritten the change from string to int for id's.
I know I am not going to do it 8-).

A bigger issue is how the vcs backend does locking/isolation to prevent parallel updates
from being committed where one of the updates isn't complete. Currently in Roundup
the database is locked (dbm) or runs changes inside a transaction (sql backends) to
prevent parallel changes from mixing.