[ 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.) > > > > 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. > 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 case of a replacement, do we want the API to provide the replaced node's properties? (at least their names) > >> + /** The name of the property */ > >> + const char *name; > >> + > >> + /** Pointer to the next sibling property */ > >> + struct svn_repos_node_prop_t *sibling; > >> + > >> +} svn_repos_node_prop_t; > >> +
