[ The second hunk below has a discussion regarding the representation in the API of 'svn ps k v iota; svn ci iota; svn cp iota iota2; svn ps k2 v2 iota2; svn ci iota2', which I'd be happy to have further input on. ]
Erik Johansson wrote on Wed, Dec 22, 2010 at 23:08:30 +0100: > On Fri, Dec 10, 2010 at 15:08, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > [ I'm somewhat confused about this issue. ] > > > > Erik Johansson wrote on Thu, Dec 09, 2010 at 21:41:38 +0100: > >> On Wed, Dec 8, 2010 at 23:22, Daniel Shahaf <d...@daniel.shahaf.name> > >> wrote: > >> > Erik Johansson wrote on Wed, Dec 08, 2010 at 17:17:47 +0100: > >> >> + /** How this property entered the node tree: 'A'dd, 'D'elete, > >> >> 'R'eplace */ > >> >> + char action; > > > > I should have caught this earlier, but "replaced" doesn't make sense > > for properties. (A node can be replaced by another node at the same > > path, but for a fixed node properties can be added/modified/removed but > > not replaced.) > > I'll change it to 'A'dd, 'D'elete or 'U'pdate then? > 'M'odify, not 'U'pdate, I think. At least that's what the UI level does, but if there's precedent for 'U'pdated then follow it. > >> > > >> > This is copied from svn_repos_node_t->action. There was recently > >> > a question about that field: > >> > http://mid.gmane.org/3abd28aa-a2fc-4d7d-a502-479d37995...@orcaware.com > >> > > >> > So, that asks whether 'C'hanged is a valid answer to the question that > >> > ->action is meant to answer. I'll also ask how this interacts with node > >> > changes: for example; if r5 replaces-with-history a node that has > >> > 'fooprop' set with another node that also has 'fooprop' set, what would > >> > the value of 'action' be? > >> > >> What about this: > >> When a node is deleted all the properties it had are listed in > >> mod_prop with action D. > >> > >> When a node is added-with-history all the properties the source had > >> are listed in mod_prop with action A and a new flag copyfrom = TRUE. > >> > > There is already a copyfrom indication in svn_repos_node_t->copyfrom_rev, > > I don't think we need another one. > > I was thinking that the copyfrom flag would be useful in the case > where you copy a node with a propery and add another property before > committing. Here you would have two property with action A and one > would have copyfrom = TRUE. > In other words, you'd like to make a distinction between "This node was added-with-history, and this property came along" and "<ditto>, but the property is new on this copy target and didn't exist in the copy source". I see, and I agree it's a good distinction to make. I'm not sure how/whether our other API's (the editor, possibly the reporter, others?) represent this. > >> A replace-with-history will result in two repos_nodes, each having a > >> mod_prop list. If the same property exists in both it means it has > >> been replaced. > >> > > Two nodes doesn't sound like a good idea; one node marked as 'replaced' > > should suffice. > > In the current api a replaced node is represented by two nodes. Should > we change this? Doesn't that mean that API callers who want to distinguish a replace from a remove or an add have to walk through all the child entries (for a given dir) before they can process any adds or removals? I'm thinking that one entry is better, because callers can split it if they wish; that's easier than two entries and letting callers figure out for themselves how to recombine them. > Should svnlook stay back-wards compatible and print a > replaced node twice, once as Deleted and once as Added? > I could argue both ways: it should be back-compatible with itself, but it should also be compatible with the cmdline client where the latter prints just one "R" notification. > > In case of a replacement, do we want the API to provide the replaced > > node's properties? (at least their names) > I suppose we can agree to answer this as "Yes", then? :) > It would be pretty simple if there are two separate nodes for a > replaced node. The deleted node will have all the properties it had > marked as Deleted. The new node will have its properties marked as > appropiate. > That's a straightforward representation, yes. I suppose we could find a straightforward in the "single node" case, though --- eg by adding fields only used in the case of 'R'eplacements. > // Erik > > -- > Erik Johansson > Home Page: http://ejohansson.se/ > PGP Key: http://ejohansson.se/erik.asc
