"Giovanni Bajo" <rasky@develer.com> wrote on 09/15/2006 11:07:22 AM:
> Paul Burba wrote:
>
> > The code was committed to trunk in early August. It's not called
> > takeover anymore - you can dig through the threads on "takeover" if
> > you are curious about the gory details as to why
> > http://svn.haxx.se/dev/...
>
> I tried, but the threads are pretty long and it's not immediately clear
what
> is the final "result" of the discussions.
Heh, I called the details "gory" for a reason :-)
> I'll try ask my question anyway.
>
> Was it considered to treat new files in an obstructed directory as
> "scheduled add", and non-existing files in an obstructed directory as
> "scheduled delete"?
Hi Giovanni,
My memory is a bit fuzzy on this, but as I recall these ideas were
abandoned, or at least put off, because they both try to guess the user's
intent a bit too much. In the case of "new" (i.e. unobstructing
unversioned) files in a directory, perhaps the user *really* wants these
to remain unversioned. Yes, I know they could revert them after the fact,
but they could just as easily add them after the fact too. I think this
is a case where some group of people will be unhappy no matter what the
behavior is(?). On a related note, I am currently working on a patch that
will allow up/sw/co to tolerate obstructions that are scheduled for
addition without history (i.e. through svn add, not svn copy or move) -
see http://svn.haxx.se/dev/archive-2006-09/0459.shtml. This would solve,
or at least partially alleviate, this problem since the user can just add
the unversioned files/dirs they want to become versioned before running
the forced update.
Re non-existing files becoming scheduled for deletion, again I think this
tries to get in the mind of the user too much.
Please take all this for what it is: my opinion! If someone can
demonstrate a real need for further enhancements co/sw/up --force, can
clearly articulate the desired behavior, and can get some agreement from
the community that it's a "good thing" then it can happen.
> If this was the case, "svn checkout --force" would
> automatically do much of the job of svn_load_dirs.pl, and thus would be
> dramatically useful for vendor branches.
Sorry, I'm not familiar with svn_load_dirs.pl so I'll have to let someone
else speak to that.
Paul B.
> Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 15 17:39:37 2006