On Wed, Mar 24, 2010 at 16:41, Philip Martin <philip.mar...@wandisco.com> wrote: > neels <nee...@gmail.com> writes: >> On 23 March 2010 09:11, Greg Stein <gst...@gmail.com> wrote: >>> On Mon, Mar 22, 2010 at 17:59, Philip Martin <philip.mar...@wandisco.com> >>> wrote: >>>> $ svn cp $url/A wc >>>> $ svn add wc/A/Y >>>> >>>> Suppose $url/A contains $url/A/X. How do I distinguish between a >>>> copied child, like wc/A/X, and an added node like wc/A/Y? Neither has >>>> copyfrom set. How do I know that A/X inherits from it's parent A >>>> while A/Y does not? >>> >>> Yes, you brought up this hole in the design a while back, and we've >>> had some discussion on ways to solve it. > > As I recall the last problem was a copied child that was first deleted > and then replaced, and the problem is that there is only one working > node to represent both the deleted and added nodes. > > This problem is vaguely similar but here we have two working nodes, so > we have enough storage is just a matter of deciding which values to > store.
Okay. >>> As Bert points out, you can >>> use changed_* to detect the local-add, rather than local-copies. >>> >>> We may introduce a special copyfrom_* value to indicate "local-add" >>> rather than "copy-from". Or maybe rely on changed_*. It is unclear on >>> what is the best approach right now. > > We should consider using copyfrom_repos_path. The current method of > only storing copyfrom_* on the root of the copy means that > copyfrom_repos_path needs to be calculated every time its value is > required. I doubt that we use it independently of the other fields, so scanning upwards for the others can also compute the relpath. We do the same thing for the regular repos_id and repos_relpath. > The other copyfrom_* fields contain the same value through > the copy, so it makes sense to elide those where possible. We could > use something like: > > copyfrom_repos_id == NULL copyfrom_repos_path == NULL : added, no copy > copyfrom_repos_id != NULL copyfrom_repos_path != NULL : root of copy/move > copyfrom_repos_id == NULL copyfrom_repos_path != NULL : child of copy/move Not sure about this. >> May I suggest to use the WORKING node's 'presence', as we already do >> with subpath deletions inside copied trees. A presence of >> 'not-present' currently indicates that a subpath of a recursive copy >> is excluded from the copy, IOW that it is the root of a delete >> operation inside a copy. A new value called 'not-related' could >> indicate that a path is the root of an *add* operation that is not >> related to the add operation of its parent. > > I suppose we could, but I think we already have enough storage for > this problem. If we were to adopt a new presence I think I'd make the > copied child have the new value. Nodes that are simple adds are very > similar to nodes that are the root of a copy: both represent new items > in the repository and it seems reasonable that they have the same > presence value. Copied children are the ones that are special or > different. Children of copies/moves/adds are all about the same. I think it is the root that stands out, especially because it is *that* node where we store the copy/move information. Thus, I would suggest a presence named "root" or "oproot" (operation root). This will solve the "add into another operation's tree", but it does not solve the "did I replace a node in that tree? thus, do I need to issue a DELETE before issuing this new operation?" Having a "root" presence also means we can easily scan upwards for the base of an operation. Hmm. Tho I guess the base of a deletion wouldn't be marked root... Anyways. Any thoughts? Cheers, -g
