|Re: [jgit-dev] Exceptions in jgit|
Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote: > > > > I'd like to move to more specific checked exceptions, and stop > > throwing back any old IOException to the application caller. > > But this is a fairly major effort, and I'm just struggling to > > get the sideband protcol change implemented to match Git 126.96.36.199. > > I've basically written it off as something I just can't do. > > There's more than just one person on the project, though, right? Yes, quite a few. :-) > Do we have an externalised list that isn't in Shawn's head of > things-that-you'd-like-to-do-but-don't-have-time? It seems like > a fairly boring but sufficiently easy task for the conversion > to occur, and makes sense to be done prior to a 1.0 release (but > probably after the 0.7 EclipseCon release). No. Because I haven't bothered to write them down. Also, some of them I think are just obvious. The exceptions are clearly somewhat ugly, Sasa noticed it and wondered WTF. WTF is, it needs work, but nobody has been able to do it yet. As long as we're stating my wishes: * I also want a fully in-memory Repository. That is, one that stores everything in say HashMap and never touches java.io.*. Then we can put nearly all of the unit tests onto this repository type, and only need to use local java.io to test the java.io variant. I know at least one person wanted a JDBC Repository, and I'd like a Repository on top of say Apache Cassandra... I think it might make scaling a Gerrit installation across hardware easier. * I also want Repository and WorkTree split. IMHO repository shouldn't have getWorkTree() method. Not every repository really has a working directory attached to it, and they might use an index that isn't at $GIT_DIR/index. I'd like to have Repository be the bare "git stuff", that is refs, objects, config, transport. And have some other type, e.g. WorkTree, have the Repository, DirCache/GitIndex, and top level working directory. In theory this might make it easier to have working directory *not* on local filesystem. Imagine instead using the IResource APIs for all work tree access inside of Eclipse, it would probably play nicer with the Eclipse VFS in the workspace. It also might open the door to a "git workspace in the cloud". E.g. what if you took Bespin and used it as an editor, and wanted to permit the creation and editing of merges in the cloud? We would need lots of WorkTree objects (one per active "checkout"), but only one Repository. This last one actually might be less practical to do, or less necessary, than just getting the IO abstracted. -- Shawn.
Back to the top