Hi,
I made a second thought, and I'm no longer sure I would allow a revision to be
reachable by some client interaction. In the current design, the GC will copy
the head revision to the to store plus all the revisions that are either
newly created (by some commit call coming in later) or still
Hi,
On Tue, Apr 3, 2012 at 11:47 AM, Dominique Pfister dpfis...@adobe.com wrote:
I made a second thought, and I'm no longer sure I would allow
a revision to be reachable by some client interaction.
You'd drop revision identifiers from the MicroKernel interface? That's
a pretty big design
Hi,
On Apr 3, 2012, at 11:51 AM, Jukka Zitting wrote:
Hi,
On Tue, Apr 3, 2012 at 11:47 AM, Dominique Pfister dpfis...@adobe.com wrote:
I made a second thought, and I'm no longer sure I would allow
a revision to be reachable by some client interaction.
You'd drop revision identifiers
rules on the expected
lifetime of revision identifiers. Without rules like that a client
can't even do the following without worrying about potential
interference from the garbage collector:
String revision = mk.getHeadRevision();
String root = mk.getNodes(revision, /);
Since the revision
Hi,
On Mon, Apr 2, 2012 at 6:34 PM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
i don't think that we should allow clients to explicitly extend the life span
of a specific revision. this would IMO unnecessarily complicate the GC
logic and it would allow misbehaved clients to
that *no* past state of the repository should
ever be automatically cleaned out as garbage.
To allow automatic garbage collection without unexpectedly breaking
client expectations, we should define some rules on the expected
lifetime of revision identifiers. Without rules like that a client
can't
