On 9/15/06, Paul Burba <paulb@softlanding.com> wrote:
> "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 know I'm late into this discussion, but I'm wondering if the new
"--force" functionality for up, co, and sw (especially up) can be
found in any stable branch, or any branch other than trunk. This is
one feature I've been dreaming of since hitting my first
"unversioned... exists, failed update" type error, and I want it ASAP!
I've written wrapper tools to do pretty much the same thing, as well
as work-around Windows file lock issues, but I'm sure the core code
does it much better than my script.
> Re non-existing files becoming scheduled for deletion, again I think this
> tries to get in the mind of the user too much.
I must agree on this point! In our case, we version a lot of
built-data (like .exe, but for art) and in-between data (like .o
files, but again for art), and we have a lot of debug, text, and log
data in the same directories that we don't feel the need to version,
but like to keep around for reference. When two people build the same
source at the same time, and attempt to commit at different rates, the
last to commit "loser" often gets stuck with a mess of update errors
and cleanups to run through. Deleting the log and reference files
would be less of a penalty than the current situation, but perceived
as a penalty nonetheless. I agree with the usual Subversion rule of
"don't destroy local data unless specifically instructed, via delete,
revert, etc". I view this form of previously-unversioned match version
tagging as completely non-destructive.
In cases where the user wants to delete unversioned files after an
up/co/sw --force, it should be a lot easier to script it afterwards by
parsing the recursive status output data. Certainly that would be much
easier than trying to recover any lost data, caused by an accidental
mis-use of destructive commands on non-versioned files.
> 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.
I think the behavior already described in this thread matches our
use-case exactly -- better than the current default Subversion
behavior. The need for a SVN_ERR_WC_OBSTRUCTED_UPDATE never made any
sense to me at all. In fact, I don't quite see why using a flag like
"--force" should be necessary to attain this behavior at all! Why
can't this be the default up/co/sw behavior?
Thanks,
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 16 09:28:32 2006