On Tuesday 18 November 2003 17:00, you wrote:
> On Tue, 2003-11-18 at 18:54, Delbert D. Franz wrote:
> > This hits a snag. Under Windows, where this work is being
> > done, the copy commands seem to always change the time
> > stamp on the directories when new ones are created.
> > This change causes Subversion to claim that all files have been changed.
>
> You're wrong about this. Changing timestamps on either working files or
> hidden 'text-base' files does *not* make Subversion think they're
> changed. It just makes it take longer for Subversion to figure out
> whether they're changed or not.
>
> So if 'svn status' says that every file in your working copy has
> changed, then something is deeply wrong. Try running 'svn diff' on one
> of the files, and see how it has changed.
Yes I was wrong about the inference on timestamp differences. However,
the problem turns out to be a bit subtle. I have a work around but I
wonder why the problem arises. Here are the details:
My LAN has five machines on it: three are running Libranet 2.8.1, based
on Debian using the 2.4.21 kernel, and two virtual machines under VMware
4.0.5 are running W2K Pro. These W2K machines are on my laptop
and desktop respectively and use bridged networking so they appear on the LAN
with their own static IP address.
The final Linux machine is the web server and Subversion repository.
I use auto-prop and set svn:eol-style=native on all text files. The
config file with auto-prop enabled exists on all five machines.
Subversion is at 0.32.1 everywhere in the LAN.
Here is what is happening:
1. I import the repository from W2K on my desktop. That goes without
a hitch. I then checkout a working copy to my F: drive on the same
W2K machine. A svn diff on a file and svn status on the whole working
copy show no mods at all as they should. The end of line is CR-LF as
it should be.
2. I create an archive of the working copy using Info-zip's zip 2.3,
the last one issued. This all takes place in W2K. I then copy
this archive to my laptop W2K via the LAN. The options used
for making the archive are -rSq: recursive on directories, include
hidden and system files, and do it quietly!
3. On the laptop I unzip the archive using Info-zip's unzip 5.5,
again the last release for Windows.
4. In this new working copy a svn status shows every file
has been modified. Note that nothing has been done on
Linux. A svn diff of a text file shows after some work,
that svn thinks that the working copy of the file now has
only line feeds for eol and the base-copy has cr-lf. However,
a scrutiny of the working copy shows that it still has cr-lf
at the end of every line!
5. This curious result demanded some more work. I therefore
recreated a new working copy on the desktop and
did a command-line copy of it from the drive
on the desktop to the drive on the laptop, again all in Windows.
This fresh working copy was then correct. svn status showed
no changes and svn diff on a file showed no changes. The same
result was obtained using an Explorer drag-and-drop copy of
the working-copy directory.
6. I often mount the W2K drives on my desktop in Linux on
the desktop using smbfs. I did that to look at the working
copy on W2K with Visual Slickedit, my current editor under
Linux. It shows end of line characters clearly. This check
showed that the end of line characters for the W2K file
were correct. However, after this operation, this file
then showed modifications using svn diff-claiming again
that the end-of-line character was a line feed only!
This happens if the file is examined using the Linux
less command also.
7. Finally I downloaded a trial versiion of PKZIP se 6.00d
and created an archive of a fresh checkout and transfered
it to my laptop. When unzipped the working copy on
the laptop showed no changes using svn status. Thus
the transfer was OK.
Several hours of testing yields the following conclusions:
1.Info-zip's zip and unzip must change some aspect of the
file information that causes svn to think the file is a Linux
file. However, this change is hidden from the ordinary
user.
2. Mounting a shared drive on W2K in Linux using smbfs
and then accessing the file with an editor or the less
command does the same thing, Also backing up the
files on the mounted drive with software running in Linux
leaves the same modifications. svn diff and svn status
are convinced that the files in the working copy
have a eol character of LF when in fact they have CR-LF.
3. The work around for me is to never mount the W2K drives
in Linux. I will have to shift to making transfers between
the virtual W2K machine and the real Linux machine from
W2K. VMware provides that capability. Also do not
use Info-zip software to create an archive. Make a direct
copy or use PKZIP.
Sorry for the long message but the non-obvious nature of the
problem required quite a lot of detailed testing before I came
to a work-around that I can use.
This problem potentially arises in any mixed LAN whenever a
W2K shared drive is mounted in Linux and any file in the
working copy is accessed with less or an editor. That file
will be flagged as having had a complete change in eol
character by svn status, svn diff, and svn commit.
This is not the expected result of what seems to be an
innocuous operation in a mixed LAN.
Thanks for getting back so quickly and putting me on the
right track to a work around.
Delbert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 19 23:28:23 2003