On 13 Apr 2007, at 21:30, Ryan Schmidt wrote:
>
> 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.
I understand that the latest Apple Developer applications do
preserve .svn. Xcode.app has embedded svn support; this was based
around v1.3.2, and has recently been updated to work around an
imcompatibility with v1.4. I am using an older release of WebObjects
Builder.app. Even if I were using the latest release, there are lots
of other non-developer applications such as Keynote.app where this
problem will crop up.
...
> 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?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[1] create a mickey-mouse project
mkdir -p /tmp/testproject/branches
mkdir -p /tmp/testproject/tags
mkdir -p /tmp/testproject/trunk/wrapper
cd /tmp/testproject/trunk
cat <<+ >a.txt
this
+
cat a.txt > wrapper/wrapped.txt
[2] import to repository
[3] change the project; verify your changes manually
cat <<+ >a.txt
that
+
find wrapper -exec ls -ld {} \;
cat a.txt > wrapper/wrapped.txt
rm -rf wrapper/.svn
find wrapper -exec ls -ld {} \;
[4] make a backup copy of the project, eg
gnutar -tf /tmp/testproject.tar .
mkdir /tmp/testproject-bak
gnutar -xf /tmp/testproject.tar --directory /tmp/testproject-bak
[5] svn status (i)
svn status should show wrapper as obstructed and show a.txt as changed
[6] svn status (ii)
svn status a second time will not show wrapper at all and show a.txt
as changed
[7] svn diff
svn diff will show a.txt but not wrapper/wrapped.txt
find wrapper -exec ls -ld {} \; will show that wrapper/.svn has
been recreated
[8] diff
diff -r /tmp/testproject /tmp/testproject-bak shows that wrapper/.svn
was recreated sourcing pristine copies from the working copies.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
>> 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.
Looking at the "opaque collections" ticket ... clientside scripts as
per http://subversion.tigris.org/issues/show_bug.cgi?id=1152 is
probably the way forward.
If anybody does take on "opaque collections" for Subversion ... I
wish you more success than Apple managed with tar wrappers in CVS!
--
Patrick Middleton
OneStep Solutions plc
351 London Road Phone: +44 (0)1702 426400
Hadleigh Fax: +44 (0)1702 556855
Essex. SS7 2BT Email: patrick@OneStep.co.uk
England (MIME welcome)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 16 11:25:46 2007