Skip to main content
[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.

Back to the top