Julian:
Given the required RA protocol changes, when could this change be shipped?
What version of SVN?
Thank you.
Doug
On Wed, Feb 19, 2014 at 10:06 AM, Julian Foad julianf...@btopenworld.comwrote:
Marc Strapetz wrote:
Julian Foad wrote:
It looks like we have an agreement in
On 21.02.2014 15:50, Doug Robinson wrote:
Julian:
Given the required RA protocol changes, when could this change be
shipped? What version of SVN?
We treat a protocol extension the same way as an API extension: new
protocol-level features can only appear in minor version releases (e.g.,
1.9.0
Doug Robinson wrote:
Julian:
Given the required RA protocol changes, when could this change be
shipped? What version of SVN?
Hi Doug. A change like that could be shipped in a 1.x.0 version.
- Julian
Julian Foad wrote:
Marc Strapetz wrote:
Julian Foad wrote:
It looks like we have an
On 18.02.2014 15:26, Julian Foad wrote:
Marc Strapetz wrote:
On 17.02.2014 18:36, Julian Foad wrote:
Marc Strapetz wrote:
Hence an API like the following should work well for us:
interface MergeinfoDiffCallback {
void mergeinfoDiff(int revision,
MapString,
Marc Strapetz wrote:
Julian Foad wrote:
It looks like we have an agreement in principle. Would you like to file an
enhancement issue?
Great. I've filed an issue now:
http://subversion.tigris.org/issues/show_bug.cgi?id=4469
Would you please review the various attributes (Subcomponent,
On 19.02.2014 16:06, Julian Foad wrote:
Marc Strapetz wrote:
Julian Foad wrote:
It looks like we have an agreement in principle. Would you like
to file an enhancement issue?
Great. I've filed an issue now:
http://subversion.tigris.org/issues/show_bug.cgi?id=4469
Would you please
On 17.02.2014 18:36, Julian Foad wrote:
Marc Strapetz wrote:
... I'll dig into the cache code ...
I did that now and the storage is quite simple: we have a main file
which contains the diff (added, removed) for every path in every
revision and a revision-based index file with constant
Marc Strapetz wrote:
On 17.02.2014 18:36, Julian Foad wrote:
Marc Strapetz wrote:
Hence an API like the following should work well for us:
interface MergeinfoDiffCallback {
void mergeinfoDiff(int revision,
MapString, Mergeinfo pathToAddedMergeinfo,
Marc Strapetz wrote:
... I'll dig into the cache code ...
I did that now and the storage is quite simple: we have a main file
which contains the diff (added, removed) for every path in every
revision and a revision-based index file with constant record length (to
quickly locate entries in
I took a stab at writing the JavaHL boiler-plate code for this, as attached,
though I'm unfamiliar with JavaHL. It seems to require modifying 5 java files
and creating 3 new ones. Is that right, JavaHL experts? It seems a lot.
The implementation in the core library is empty, as yet, in the
On 17.02.2014 22:25, Julian Foad wrote:
I took a stab at writing the JavaHL boiler-plate code for this, as attached,
though I'm unfamiliar with JavaHL. It seems to require modifying 5 java files
and creating 3 new ones. Is that right, JavaHL experts? It seems a lot.
It's about right. Welcome
For SmartSVN we are optionally displaying merge arrows in the Revision
Graph. Here is a sample image, how this looks like:
http://imgur.com/MzrLq00
From the JavaHL sources I understand that there is currently only one
method to retrieve server-side mergeinfo and this one works on a single
Marc Strapetz wrote:
For SmartSVN we are optionally displaying merge arrows in the Revision
Graph. Here is a sample image, how this looks like:
http://imgur.com/MzrLq00
From the JavaHL sources I understand that there is currently only one
method to retrieve server-side mergeinfo and this
On 14.02.2014 11:38, Julian Foad wrote:
Marc Strapetz wrote:
For SmartSVN we are optionally displaying merge arrows in the Revision
Graph. Here is a sample image, how this looks like:
http://imgur.com/MzrLq00
From the JavaHL sources I understand that there is currently only one
method to
I (Julian Foad) wrote:
Can we think of a better way to design the API so that it returns the
interesting data without all the redundancy? Basically I think we want to
describe changes to mergeinfo, rather than raw mergeinfo.
Marc,
Perhaps a better way to ask the question is: Can I
On 14.02.2014 11:38, Julian Foad wrote:
Marc Strapetz wrote:
For SmartSVN we are optionally displaying merge arrows in the Revision
Graph. Here is a sample image, how this looks like:
http://imgur.com/MzrLq00
From the JavaHL sources I understand that there is currently only one
method to
Can we think of a better way to design the API so that it returns the
interesting data without all the redundancy? Basically I think we want to
describe changes to mergeinfo, rather than raw mergeinfo.
Marc,
Perhaps a better way to ask the question is: Can I encourage you to write the
Marc Strapetz wrote:
Can we think of a better way to design the API so that it returns the
interesting data without all the redundancy? Basically I think we want
to describe changes to mergeinfo, rather than raw mergeinfo.
Marc,
Perhaps a better way to ask the question is: Can I
Branko Čibej wrote:
On 14.02.2014 11:38, Julian Foad wrote:
Can we think of a better way to design the API so that it returns the
interesting data without all the redundancy? Basically I think we want
to describe changes to mergeinfo, rather than raw mergeinfo.
I wonder, Julian, could
On 14.02.2014 14:18, Marc Strapetz wrote:
Can we think of a better way to design the API so that it returns the
interesting data without all the redundancy? Basically I think we want to
describe changes to mergeinfo, rather than raw mergeinfo.
Marc,
Perhaps a better way to ask the
20 matches
Mail list logo
