On Sat, 2009-01-31 at 11:02 -0500, Mark Phippard wrote:
> On Fri, Jan 30, 2009 at 5:58 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> > On Wed, Jan 28, 2009 at 3:48 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> > Julian (and/or any other TCers),
> >
> > I've got this test working, but I'm wondering about a slightly
> > different case than the one covered in the test.
> >
> > What if, instead of having a modification directly to the directory
> > that the update will attempt to delete, we instead have a local mod
> > only to a subtree of that directory? For example, say we start with
> > this vanilla Greek WC:
> >
> > issue3334.dgb>svn st -v
> > 1 1 jrandom .
> > 1 1 jrandom A
> > 1 1 jrandom A\B
> > 1 1 jrandom A\B\lambda
> > 1 1 jrandom A\B\E
> > 1 1 jrandom A\B\E\alpha
> > 1 1 jrandom A\B\E\beta
> > 1 1 jrandom A\B\F
> > 1 1 jrandom A\mu
> > 1 1 jrandom A\C
> > 1 1 jrandom A\D
> > 1 1 jrandom A\D\gamma
> > 1 1 jrandom A\D\G
> > 1 1 jrandom A\D\G\pi
> > 1 1 jrandom A\D\G\rho
> > 1 1 jrandom A\D\G\tau
> > 1 1 jrandom A\D\H
> > 1 1 jrandom A\D\H\chi
> > 1 1 jrandom A\D\H\omega
> > 1 1 jrandom A\D\H\psi
> > 1 1 jrandom iota
> >
> > Then we delete 'A' directly in the repos:
> >
> > issue3334.dgb>svn del %url53%/A -m ""
> >
> > Committed revision 2.
> >
> > Then we make a text mod in our WC to a subtree of 'A':
> >
> > issue3334.dgb>echo new content > A\D\G\pi
> >
> > issue3334.dgb>svn up
> > C A
> > At revision 2.
> > Summary of conflicts:
> > Tree conflicts: 1
> >
> > Ok, the tree conflict is correct, but what should be scheduled for
> > addition? Should the entire subtree rooted at 'A' be schedule for
> > addition as a copy from A_at_1?
> >
> > issue3334.dgb>svn st -v
> > 2 2 pburba .
> > A + C - 1 jrandom A
> > > local edit, incoming delete upon update
> > + - 1 jrandom A\B
> > + - 1 jrandom A\B\lambda
> > + - 1 jrandom A\B\E
> > + - 1 jrandom A\B\E\alpha
> > + - 1 jrandom A\B\E\beta
> > + - 1 jrandom A\B\F
> > + - 1 jrandom A\mu
> > + - 1 jrandom A\C
> > + - 1 jrandom A\D
> > + - 1 jrandom A\D\gamma
> > + - 1 jrandom A\D\G
> > M + - 1 jrandom A\D\G\pi
> > + - 1 jrandom A\D\G\rho
> > + - 1 jrandom A\D\G\tau
> > + - 1 jrandom A\D\H
> > + - 1 jrandom A\D\H\chi
> > + - 1 jrandom A\D\H\omega
> > + - 1 jrandom A\D\H\psi
> > 2 1 jrandom iota
> >
> > *OR* should only the modified subtree 'A/D/G/pi' and its path-wise
> > ancestors be present?
> >
> > issue3334.dgb>svn st -v
> > 2 2 pburba .
> > A + C - 1 jrandom A
> > > local edit, incoming delete upon update
> > + - 1 jrandom A\D
> > + - 1 jrandom A\D\G
> > M + - 1 jrandom A\D\G\pi
> >
> > 2 1 jrandom iota
> >
> > I've got the former working*, but I wonder if the latter is not
> > actually the correct behavior.
>
> I tend to think the latter would be the correct behavior, but I am not
> certain that it is so "clear-cut" that it is a must-have. My main
> concern with the former behavior is that I'd not expect the final
> desired result to be restoring the entire folder. I kid of see two
> expected final outcomes:
>
> 1) The user wants keep their changes and the file. In which case,
> they will have to do something to undo the scheduled add of all of the
> other files and folders they do not want.
OK, I can see scenarios like this, I guess. Scenarios where files stored
in a directory hierarchy are independent of each other but share the
hierarchy. So,
our-customers/
USA/
Texas/
UK/
London/
Beta Ltd.
Salesman 1 loses the last London customer and concludes we don't need
the 'UK' directory any more:
our-customers/
USA/
Texas/
Meanwhile, salesman 2 gets a new customer in London and adds it:
our-customers/
USA/
Texas/
UK/
London/
Beta Ltd.
Nova Ltd.
There is a tree conflict on the victim directory "UK". And the
resolution of the conflict is that the new "Nova Ltd." node is to be
re-created, along with its parent directories.
I was more readily seeing scenarios where a directory contains things
that are in some way connected to each other, so that restoring one on
its own would not make much sense, as is the case if, for example,
"subversion/libsvn_client/" was moved to another location and I had been
editing one of the files in it.
> 2) The user moves their changes to a renamed version of the file, or
> abadons the change. In which case they have to revert this scheduled
> add and cleanup all these files and folders. Given that they will
> probably just delete the local folder "A" and all its children that is
> probably not too hard.
Yes, that's simple and quick, e.g.: "svn revert -R blah/".
> I see scenario #1 as the problem as it would be fairly hard for the
> user to fix the WC so that they could commit just the file.
"Commit just the file" meaning "re-create as much of the tree as is
necessary to hold that file, and re-add the file there".
OK, maybe Subversion doesn't have good ways to do that.
> I do think there is some gray area here though. So if the getting
> this behavior is going to be difficult, I'd rather get the release
> done and see if people run into this and think it is wrong.
OK
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1091327
Received on 2009-02-02 17:36:42 CET