> That's a bit ugly: ideally the operation would fail atomically.
<rant>
Why does this operation need to fail? Reading through the mailing list
and archives, it seems the answer to a lot of problems is "fail
atomically", when the real obvious answer for any frequent user should
be "handle gracefully". Who cares if the file is Read-Only locally?
Add is just copying the file to the repository, so why should it need
write access to the WC file for this operation? If it needs write
access for the operation, shouldn't it attempt a chmod or the like
before failing?
All such failures seem ugly to me. Even worse are the failures
like "file locked" (meaning OS local-file lock, not repository lock,
which the message never makes clear), "failed to move blah.tmp"
followed by "cleanup failed, failed to move blah.tmp [again]". Or the
most stupid of all: "local fine not versioned" on an update attempt to
a file lacking WC status information, and rather than just leaving the
file alone and updating WC status, it fails the whole Update
non-atomically, sometimes requiring a follow-up cleanup to get
anything done again. Why is failure always the answer here?
I often work around these things with my own wrapper tools. I get
a log list from WC+1 to HEAD, renaming all files on the list to
*.~bak~, renaming back unless unversioned, in which case I rename
after update which has the same net effect as a WC-status-only update.
If I can't rename, there's obviously some kind of OS local file lock
issue, so I rename pending back then fail the whole Update operation
and let the user know about the locked file, *before* getting into a
state requireing a cleanup. I don't understand why svn client commands
can't do the same.
And these are just Update errors. Commit errors are even more
annoying. "Commit failed -- file not latest" type errors are
ridiculous. Just update the thing for me, and only bother me if
there's a merge conflict. Even if certain users don't want this to be
the default behavior (I don't know any personally), it should be at
least a config option.
I swear if the repository and bidirectional network model wasn't so
great, I would have given up on the svn client last year.
</rant>,
Jared
> > Initially I was of the impression that the operation failed, but 'svn
> > status' says operation succeed. I think users will get confused with the
> > above error message, because error looks more like a failure than a
> > warning.
> >
> > svnadmin create /tmp/repos
> > svn co file://tmp/repos /tmp/wc
> > cd /tmp/wc
> > touch foo
> > chmod -r foo
> > svn add foo
> > svn st foo
> >
> > Same happens while adding a write-only directory, but a --non-recursive
> > add or status can fix this.
> >
> > I suspect this is because svn tries to open the write-only
> > file/directory and a quick scan confirms it too. Can any one suggest a
> > better solution for this problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 29 00:33:57 2006