[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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 1.7.0.2.
> > 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.