Hello,
Fisrt, excuse me for the title if i offenced some one.
We use svn on linux and had some problem with some features.
1) We would be very happy to remove things (file,symlink,dir) from
version control BUT not to delete them. Please note that there are 2
ways, in both of them, we keep thing in the curent working copy.
One way is to let the file uppon update in another working copy. The
other is to delete it from other working copy.
As exemple , if we had dynamicly generated files (stats), we want not
to get them under version control but to keep them on local wc and
distant wc .
The other case is when you got your own litle test script in your wc and
want to delete it from the repository and other's wc.
Both example are initiated by an add error (lot of things in a directory).
2) We encounter an error when removing a symlink.
The symlink was pointing to a directory. When we run 'svn remove slink',
the utility seems to look INTO the pointing directory and return an
error (normal). The workaround way i found is to delete first the
symlink ('rm slink') and only after run ths svn command.
=> 'svn delete' should first look at the thing asked to be deleted if it
is a symlink.
3) We are working with apache and suexec, but all permission of the
files are not keept. It seems that only the user's perms are saved but
not the group nor the other perms. Is there a plan to manage them into
svn ?
4) A "write" access denied seems to lock the working copy (only the
just above directory of the error). For example, an subdir as different
user owner. The workarround is to edit by hand the .svn/entries of the
dir containing the bad subdir and delete any reference to that subdir.
Svn commit into database is atomic, but svn command on the working
commit are not. Am I the only one to get that sort of problem, not the
bad user owner (that is a bad administration of the wc) but the crash of
'svn add' (or 'import') that need human work ?
=> atomic operation on the working copy ?
Another point is that svn rocks :) Even if this emails contains more bad
than good.
B.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 17 10:55:15 2005