On Apr 13, 2007, at 10:58, Patrick Middleton wrote:
> I'm working with svn 1.4.3 on MacOSX 10.4. I have an old problem
> and a new one.
>
> The old problem is that I'm working on MacOSX, and many things
> which look like files are actually directories which contain a
> standard layout of files within them. A fine example is Main.wo ;
> this is a WebObjects component, and is actually
> drwxr-xr-x Main.wo/
> -rw-r--r-- Main.wo/Main.html
> -rw-r--r-- Main.wo/Main.wod
> -rw-r--r-- Main.wo/Main.woo
>
> If this component is part of a project versioned in Subversion,
> there will also be a directory Main.wo/.svn/ too of course, the
> 'Working Copy Administration Area'. There are are editor
> applications such as WebObjects Builder.app for modifying these
> document packages supplied with Apple Developer Tools; in the case
> of WebObjects, the three files inside the document wrapper are
> text, so you don't have to use the GUI editor application, but it's
> usually convenient too. Inevitably, when saving a modified
> document, the editor application doesn't preserve the .svn
> directory. That's the old problem; when users of CVS instead of
> Subversion, I'm told it's far worse.
This would be fixed if Subversion would implement support for "opaque
collections" as per this ticket:
http://subversion.tigris.org/issues/show_bug.cgi?id=707
However that feature is unscheduled. In the mean time, you would have
to convince Apple to modify WebObjects Builder.app to not destroy
the .svn data when saving. They have already made similar changes to
Xcode.app (or was it Interface Builder.app? I forget) so this request
is not so unlikely to be implemented.
> The new problem is what happens next. It is usual for either or
> both of Main.wo/Main.html and Main.wo/Main.wod to have changed at
> this point. I do 'svn status' and Main.wo shows up with a status
> of '~', which doesn't get much discussion in any of the
> documentation I remember reading, and the Main.html and Main.wod
> files do not show up at all. In http://svnbook.red-bean.com/
> nightly/en/svn-book.pdf [I'm looking at "For Subversion 1.4,
> (Compiled from r2747)"] this status code isn't mentioned in the
> "See an overview of your changes" section. Later on there's some
> Python code which suggests that '~' means "obstructed", and
> Googling for 'svn obstructed' offers an explanation.
Right, it's obstructed: the object Subversion expected to be there (a
Main.wo directory containing a .svn directory) was not there, and a
different object (a Main.wo directory without a .svn directory) was
there in its place.
If you feel the documentation is incomplete you should submit
feedback (or, better yet, a patch) to the book's mailing list.
> Then, I do 'svn status' again and Main.wo and doesn't show up
> either! I haven't been through the svn source code to discover
> what it's doing, but it appears that svn realises during the first
> 'svn status' that the Working Copy Administration Area is missing
> and builds a new one; but the Working Copy Administration Area
> contains "Pristine (un-edited) copies of the working copy files".
> The new pristine files aren't copies of what's in the repository;
> they're copies of my working copies, which I've edited.
I've never heard of Subversion automatically creating new .svn
directories. In fact I've heard many times on this list how people
who inadvertently destroyed their .svn directories have to manually
recreate them.
> Now, being a naive user who hasn't memorised the documentation, I
> think that 'svn status' is showing me the changes of my working
> copy against the repository. It's not, it's showing me the
> differences between my working copy and the pristine copy held by
> the Working Copy Administration Areas. And svn certainly hasn't
> told me that one of the Working Copy Administration Areas has been
> recreated. So I know I've got changes to commit, but 'svn status'
> says not.
>
> I then realise what's happened and try 'svn update' on the
> versioned directory and files I know I've changed; neither the
> files nor the pristine copies change.
>
> I realise that this my fault for allowing Main.wo/.svn/ to get
> trashed, but why is svn working against me like this?
I cannot offer an explanation. Subversion should not be behaving like
that. Can you show us a reproduction recipe that we could try on our
own machines which starts from the creation of a new empty repository
and the import of a few files and directories and ends with the
behavior you have just described?
> The only way I've found to fix this so far is to check out a second
> copy of the project, and copy .../second/project/Main.wo/.svn
> to .../first/project/Main.wo/.svn . I'm sure there must be a
> better way of doing this.
No, that is the way you'll have to reconstruct the .svn directories.
Subversion does not make it easier to do this because Subversion
wants to encourage you not to mess with the .svn directories. I
realize you didn't do so intentionally or even directly, but
Subversion unfortunately doesn't see those distinctions.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 13 22:31:22 2007