[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [jgit-dev] jgit-dev Digest, Vol 54, Issue 14
- From: Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>
- Date: Thu, 29 May 2014 11:25:08 +0200 (CEST)
- Delivered-to: email@example.com
- Thread-index: HMI0xuTSBGEftLrSLYgCMxw2Tm6Qmw==
- Thread-topic: jgit-dev Digest, Vol 54, Issue 14
----- Ursprungligt meddelande -----
> FrÃn: "Adrian" <adrian.wilkins@xxxxxxxxx>
> Till: jgit-dev@xxxxxxxxxxx
> Skickat: torsdag, 29 maj 2014 10:51:49
> Ãmne: Re: [jgit-dev] jgit-dev Digest, Vol 54, Issue 14
> I'd like to see abstract Path support, particularly in the working tree
> (I'm aware they are somewhat abstract already for things like IDE
> as I'd quite like to extend things to support working trees that are not
> stored in a
> traditional file system.
I haven't really looked into creating a "new" API or creating subclasses of File.
The latter may be a way of overcoming the lock-in on File. It's probably a bad
idea for some reasons (why was Path introduced if extending File wasn't a good idea).
It'd certainly required a lot of changes internally, but I think that's ok.
Please go wild, but don't expect all ideas to be accepted.
> That said, the same goes for the backend ; some of these working trees have
> counts on the order of 10^5 - 10^6 and just storing them to unpacked objects
> in a file
> system is going to cause some problems, particularly on Windows machines with
> creaky old NTFS.
JGit could certainly do a better of writing packs when adding lots of objects,
like C Git does. For that, no new API is needed, just some code.
> Things have probably moved on in the JGit codesince I last looked at this as
> well ; I visit it once in
> a while in my spare time, then pressure of work moves me away. But it's
> becoming more
> of an interest because I now have projects that would benefit from it.
> While I understand the forces of inertia that cause people to stick with
> older versions of Java
> my POV is that I don't want to encourage older versions to stick around.
> We've had enough
> trouble with the "inertia" practice causing old, insecure versions of things
> to accumulate until
> there is some real pain migrating to newer versions.
Those that didn't upgrade to the latest OpenSSL didn't have an issue with Heartbleed..
I'm all for a switch to using JDK 7 as the platform, but I'm not going to drive the
discussion. I'd just supply a +1 if it helps. JDK 6 has been officially dead
for about a year now.