[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: About Takeover feature...

From: Paul Burba <paulb_at_softlanding.com>
Date: 2006-09-15 17:39:22 CEST

"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
> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.