kfogel@collab.net writes:
> Greg Stein <gstein@lyra.org> writes:
> > > Log:
> > > * get_editor.c
> > >
> > > (svn_wc_get_actual_target): Fixes for Issue #444. It isn't enough
> > > to simply check to see if the parent is under revision control. We
> > > gotta make the parent is versioned *as our parent* !
> >
> > I'm unclear on *why* we even bother to look at the parent. That just doesn't
> > seem to make sense. For what purpose? It just kind of feels wrong, that a WC
> > directory cannot be treated as an isolated piece, but that it is *context
> > dependent* w.r.t what is the parent.
>
> +1. I am also _really_ bothered by this, as I've expressed a couple
> of times to Mike and Ben. However, when I talked with them about it,
> they had an explanation (which I can't remember now, unfortunately)
> for why this was a reasonable solution. I wasn't completely
> convinced, but nor was I able to think of a better way then.
This is part of the "anchor/target" solution to a larger problem. It
was discussed over and over, and it was decided to do things this way
a few months ago. I think it's fine to rediscuss and change our
minds, but please stop acting like this is all new. ;-)
Here's the problem in different forms:
A. Directory A/D/ has been deleted in the repository.
If I type 'svn up A/D', what should happen to my working copy?
Specifically, if the update editor's 'root' directory (which
cannot be deleted) were anchored on D (which, naively, is the
actual target of the update), nothing would happen, or we'd get
some kind of conflict. Our only recourse would be to update the
parent, A, and thereby see D removed. But we don't always want
all of A's contents updated!
B. I've made some propchanges on D, and some mods to D's children.
If I type 'svn ci A/D', what should happen?
Again, how can I distinguish between anchoring the commit editor
on D itself (thereby only committing D's children), versus
wanting to commit D's children and D *itself*? Again, the only
recourse is to commit A, and thereby possibly get extra commits
we didn't want.
Here is the current solution:
If a directory is a 'target' of a commit or update, examine its parent:
If the parent is under revision control (and really is our
parent), then anchor the editor on the *parent*, and make the
directory the 'solitary child' that gets committed or updated.
In this scenario, it's now possible for this lone directory child
to be removed, patched, etc., -- along with its children too.
If the parent isn't under revision control, then do the best we
can: anchor the editor on the original directory, and simply
update or commit the directory's children. The directory itself
cannot be affected.
So there's the explanation again, now archived for public record. No
need to discuss it right now. But at least it's out there on the
table. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:37 2006