Karsten,
Thanks for your feedback!
On 03/11/2014 11:56 AM, Karsten Blees wrote:
Am 10.03.2014 12:00, schrieb Michael Haggerty:
Reference transactions --
Very cool ideas indeed.
However, I'm concerned a bit that transactions are conceptual
overkill. How many
Am 10.03.2014 12:00, schrieb Michael Haggerty:
Reference transactions
--
Very cool ideas indeed.
However, I'm concerned a bit that transactions are conceptual overkill. How
many concurrent updates do you expect in a repository? Wouldn't a single
repo-wide lock suffice
On Mon, Mar 10, 2014 at 12:00 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
I have started working on pluggable ref backends. In this email I
would like to share my plans and solicit feedback.
No comments or useful feedback yet, except that I enthusiastically
approve of the objective and
On Mon, Mar 10, 2014 at 4:00 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
I have started working on pluggable ref backends. In this email I
would like to share my plans and solicit feedback.
Yay!
JGit already has pluggable ref backends, so it is good to see this
starting in git-core.
On 10.03.2014, at 15:30, Shawn Pearce spea...@spearce.org wrote:
On Mon, Mar 10, 2014 at 4:00 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
I have started working on pluggable ref backends. In this email I
would like to share my plans and solicit feedback.
Yay!
Yay, too!
JGit
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core. Using it from JGit requires building
SQLLite and a JNI wrapper, which makes JGit significantly less
portable. I know
Jeff King p...@peff.net writes:
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core. Using it from JGit requires building
SQLLite and a JNI wrapper, which makes JGit
On Mon, 10 Mar 2014, David Kastrup wrote:
Jeff King p...@peff.net writes:
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core. Using it from JGit requires building
SQLLite
Jeff King p...@peff.net writes:
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core. Using it from JGit requires building
SQLLite and a JNI wrapper, which makes JGit
On Mon, Mar 10, 2014 at 10:46:01AM -0700, Junio C Hamano wrote:
No to SQLLite in git-core. Using it from JGit requires building
SQLLite and a JNI wrapper, which makes JGit significantly less
portable. I know SQLLite is pretty amazing, but implementing
compatibility with it from JGit will
On Mon, Mar 10, 2014 at 05:14:02PM +0100, David Kastrup wrote:
[storing refs in sqlite]
Of course, the basic premise for this feature is let's assume that our
file and/or operating system suck at providing file system functionality
at file name granularity. There have been two historically
Jeff King p...@peff.net writes:
On Mon, Mar 10, 2014 at 05:14:02PM +0100, David Kastrup wrote:
[storing refs in sqlite]
Of course, the basic premise for this feature is let's assume that our
file and/or operating system suck at providing file system functionality
at file name granularity.
On 03/10/2014 04:52 PM, Jeff King wrote:
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core. Using it from JGit requires building
SQLLite and a JNI wrapper, which makes JGit
On Mon, Mar 10, 2014 at 2:07 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 03/10/2014 04:52 PM, Jeff King wrote:
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core.
14 matches
Mail list logo