Thu, 18 Oct 2012 19:51:07 +0200 |
Artem Tikhomirov |
Defect: use of 0 as configuration value for mapio boundary results in every file being memmap-ed
|
Mon, 18 Jun 2012 16:54:00 +0200 |
Artem Tikhomirov |
Refactor LogFacility and SessionContext, better API for both
|
Thu, 19 Apr 2012 19:18:25 +0200 |
Artem Tikhomirov |
Issue 30: bogus IOException for mmap file on linux
|
Wed, 28 Mar 2012 18:39:29 +0200 |
Artem Tikhomirov |
FIXMEs: exceptions, javadoc
|
Thu, 22 Mar 2012 22:56:01 +0100 |
Artem Tikhomirov |
Respect long offsets in revlogs
|
Wed, 21 Mar 2012 20:51:12 +0100 |
Artem Tikhomirov |
Pull changes from smartgit3 branch
|
Mon, 05 Mar 2012 15:15:49 +0100 |
Artem Tikhomirov |
Provide more detailed information on erroneous file operation
smartgit3
|
Thu, 23 Feb 2012 01:06:24 +0100 |
Artem Tikhomirov |
Straighten out exceptions thrown when file access failed - three is too much
|
Tue, 15 Nov 2011 04:47:03 +0100 |
Artem Tikhomirov |
Add options to control DataAccessProvider, allow to turn off use of file memory mapping in particular to solve potential sharing violation (os file handle gets released on MappedByteByffer being GC'd, not on FileChannel.close())
|
Fri, 16 Sep 2011 05:35:32 +0200 |
Artem Tikhomirov |
Issue 11: Error log facility. SessionContext to share common facilities
|
Wed, 09 Mar 2011 13:16:37 +0100 |
Artem Tikhomirov |
Integer offsets and file length explictly, rather than casts throughout code. Inflater may benefit from total length hint, but shall calculate it by its own if needed
|
Wed, 09 Mar 2011 05:22:17 +0100 |
Artem Tikhomirov |
Merged branch wrap-data-access into default for resource-friendly data access. Updated API to promote that friendliness to clients (channels, not byte[]). More exceptions
base
src/com/tmate/hgkit/fs/DataAccessProvider.java@35badc16a796
|
Fri, 28 Jan 2011 03:50:52 +0100 |
Artem Tikhomirov |
Updated contact address to support@hg4j.com
|
Mon, 24 Jan 2011 03:14:45 +0100 |
Artem Tikhomirov |
Complete refactoring to org.tmatesoft
base
src/com/tmate/hgkit/fs/DataAccessProvider.java@df00f02bfdd0
|