This turned out to be a common problem related to storing a working
copy on a Samba share; this has little to do with Versions itself.
The solution is to modify the main Samba configuration file (smb.conf
in Linux), adding the following line:
delete readonly = yes
On May 13, 1:06 pm, Daniel Jam
It would help if you can be a little less vague in your descriptions.
Are you moving the folder inside Versions? (You hadn't specified
that.) If so, then yes, that's a feature that would be really nice to
have. If you're moving in the Finder, having Versions installed
(running or not) won't
Versions should do that for me.
On May 14, 10:16 am, Quinn Taylor wrote:
> It's probably because, by copying the folder, you've overwritten the
> invisible .svn directory inside the old folder, and Subversion is
> confused as to what it should do, since the working copy meta-
> information
It's probably because, by copying the folder, you've overwritten the
invisible .svn directory inside the old folder, and Subversion is
confused as to what it should do, since the working copy meta-
information can't be found.
Unfortunately, this is one of the fine points about Subversion tha
When I copy a folder into a project, overwriting an existing folder,
Versions says it is "obstructed" and I can not perform any operations
on it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Versions" group.
To po
View > Show Updates From Repository (⇧⌘U)
View > File Browser Columns > Data Status In Repository
Just be aware that it will slow down refreshes of the local status.
One of the nice things about SVN is that the local working copy stores
a copy of the base revision, so `svn status` doesn't req
how about marking the files in the folder structure which have newer
versions?
the same way as with local changes, just the other way around? so you
would have a visual clue that which files will change on an update
On May 11, 11:22 pm, Quinn Taylor wrote:
> This certainly would be a nice featu