increase foolproofness, was Re: suggestions for neater operation ...

[solo turn <so...@yahoo.com>]

--- Ben Collins <bc...@debian.org> wrote:
> > 7. svn up:
> > 	should be save for some unwise person deleting
> the
> > ".svn".
> > 	not stop with "./dir is not a working copy
> > directory",
> > 	but restore the .svn.
> 
> You are asking the impossible here. How can you
> rebuild the .svn
> directory, when not having it means you know nothing
> about where a
> working copy came from or what revision it is at?
> That's like asking for
> something from nothing If you (since you are
> comparing a lot to existing
> tools) "rm -rf CVS/", you have the same problem.
> It's even worse for
> SVN, mainly because SVN has much more metadata
> stored in that directory.
why not assume the most proble case?
- you want to have the current version
  from the server you are connecting now.
- if the source file is there, and there
  is a difference, do a merge like you
  would do it anyway (you could have edited
  the file, so the .svn is anyway incorrect).
  or ask for "leave your copy, get the copy
  from repository, or merge", like microsoft
  sourcesafe does it, if it finds diffs.
  file comparisons are done via checksumming
  or real diffs.
- in our case it was:
  - 1 time deleted .svn in some subdirectory
    (pressed "del" in explorer without warning
    and wastebasket, and did not even notice it)
  - 3 times interrupted checkout
    (nervous people who could not wait till
    the end .... were used to sourcesafe/cvs
    speed, did a "i check it out on my laptop,
    my train leaves in 10 minutes" ... and
    disconnected as soon they saw their files
    were checked out)

hmmm .... wait ... maybe you are right ... what if the
toplevel .svn is gone. did not happen here, but it is
a (rare?) possibility.

what would you suggest in this case? throw away your
whole wc directory and check out again? or check out
in the directory and the checkout knows the server,
and therefor could reconstruct the .svn?

svn is a great synergy between accessible from
everywhere, strong concept in the back (built on
standards, ...), and it's (nearly ;)) foolproof. and
the above would give svn the same level of
foolproofness than the microsoft thing.

kr, ford.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: increase foolproofness, was Re: suggestions for neater operation ...

[Ben Collins <bc...@debian.org>]

> why not assume the most proble case?

Assume?!?! Nah. You are missing the the fact that it will be possible
for each directory to come from a URL that is not logical to the one it
is in, or the ones that it contains. Take this example:

# svn co http://svn.apache.org/repo/apache/trunk apache
# cd apache/srclib
# svn co http://svn.apache.org/repo/apr/trunk apr
# svn co http://svn.apache.org/repo/apr-util/trunk apr-util

This pretty common. I do it from the current apache/apr CVS now. If
somewhere in the srclib/apr/apr-util directories I delete the .svn/
directory, there's no easy way to determine if it needs to base itself
off of the parent, or the child.

We can assume *nothing*. The user will have to suck it down,
re-checkout, and remember not to do that again.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org