Julian Foad wrote on Fri, 09 Nov 2018 10:56 +:
> It is really quite important for the feasibility of writing higher level
> code such as shelving, that WC modifications can be read and written by
> a common, abstract, interface. That is, an interface definition which
> enables a 'copy' funct
Julian Foad wrote on Fri, 09 Nov 2018 12:47 +:
> == What to Do? ==
>
> I am not currently planning to make such a change, just pointing it out
> for when and if we do make changes to the editor API.
Might want to record this idea in jira, notes/, or subversion/include/
so we don't forget it.
Branko Čibej wrote on Fri, 09 Nov 2018 12:56 +0100:
> On 09.11.2018 12:54, br...@apache.org wrote:
> > Author: brane
> > Date: Fri Nov 9 11:54:21 2018
> > New Revision: 1846237
> >
> > URL: http://svn.apache.org/viewvc?rev=1846237&view=rev
> > Log:
> > More tests for peg revision parsing.
> [...]
Julian Foad wrote:
> The "WC replay delta" is simple and about ready to commit.
r1846252.
> Implementation of the "WC delta editor" is in progress.
Currently factoring out our "copy dir from repos to WC" implementation from
these two places:
libsvn_client/copy.c : repos_to_wc_copy_single()
li
Some bugs in "svn copy URL1 URL2 WC".
These examples are in a WC checked out from
https://svn.apache.org/repos/asf/subversion/trunk
$ svn copy http://svn.apache.org/repos/asf/subversion/README
https://svn.apache.org/repos/asf/subversion/site notes/
svn: E17: Illegal repository URL ''
The pr
The delta-editor API should have a method to remove all node props of a node,
and a method to remove all children of a directory.
== Existing Use Case: Loading a Dump Stream ==
The dump-stream non-delta format uses a full list of node-props. The parser
(svn_repos_parse_dumpstream3) converts thi
On 09.11.2018 12:54, br...@apache.org wrote:
> Author: brane
> Date: Fri Nov 9 11:54:21 2018
> New Revision: 1846237
>
> URL: http://svn.apache.org/viewvc?rev=1846237&view=rev
> Log:
> More tests for peg revision parsing.
[...]
> +@Wimp("Removes E instead of reporting ENOENT or E125001 for E/@")
>
Branko Čibej wrote:
> The WC-NG with its multiple op-depths behaves like a
> limited-history repository. Your picture does lack the op-depth part,
> though; there are N layers between BASE and WORKING, unlike in the
> filesystem, where we always work against a single (base) revision.
I don't think
On 09.11.2018 11:56, Julian Foad wrote:
> Is this such a crazy idea?
Not at all. The WC-NG with its multiple op-depths behaves like a
limited-history repository. Your picture does lack the op-depth part,
though; there are N layers between BASE and WORKING, unlike in the
filesystem, where we always
The WC's main job is to compose a new revision.
While the WC also supports merge conflict resolution, a mixed-revision base
state, commit of selected parts, and many other additional features, the
fundamental purpose of the WC is to help the user prepare, review and commit a
set of changes whic
10 matches
Mail list logo