[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Strange problem with archive/extraction of working copy

From: Delbert D. Franz <ddf_at_sonic.net>
Date: 2004-02-21 00:00:31 CET

I need to create an archive of a working copy that is about
1 GB in size including files under revision control and many
that are not. The bandwidth on my server is too small
( about 130 Kbits/s) to have my user base do a checkout
and then they would have to merge the unversioned files.

The working copy in question is on a Windows 2000 Pro
operating system. I tried three different archive
products: pkzip, winace, and info-zip zip. All had the
same result: every file in the extracted working copy
was shown as changed by subversion. I am using
version 0.37 on my server (Linux) and on the clients
(W2K). The end-of-line handling is perfect. I have checked
that several times.

Here is what I did:

1. Got an external diff program for W2K, WinMerge and did
a diff:

   1.1 between working files in the working copy on the
          source drive and the extracted copy on a test
           drive. That is I had two copies of the working
            directory: one that showed everything up to date
            and the second showing all files under version
            control as changed.

   1.2 between a working file and its base text file
          in the hidden svn dir.

   1.3 between the entire working copies on both drives
          including the svn files and DB files.

2. No diff using WinMerge showed a single byte of difference
     between any pair of files!

This was most puzzling. Our son, a computer science major
and working in the field for about 6 years, suggested that I
try this on drives formatted with FAT32 instead of NTFS,
the default format used by W2K during an install.

I had the extra space so I created FAT32 partitions that
were copies of the NTFS partitions. With two drives
of each I could then archive a clean working copy on
one drive and extract it on two other drives: one
formatted with NTFS and the other with FAT32.

Here are the results:

Archive created Extracted archive on:
  on: FAT32 NTFS
                                  drive drive
----------------------- -------------- ----------------


OK--files under version control appear as up to date, as they should
NOK-all files under version control are shown as changed, as they should not!

A working copy on an NTFS drive cannot be archived and extracted
anywhere and still be correct!! This outcome was strange because I
would not expect the file system format to make such a difference.

I also checked what happend with a drag-and-drop copy using
Explorer. The results were:

Source drive Destination drive for copy
for copy FAT32 NTFS
------------------------ --------------------- -------------------


In each case a small test repository was checked out to
the source drive. Note that if the source drive is NTFS
then even a drag-and-drop copy with Explorer fails to
create a correct working copy on a FAT32 drive.

My current work-around is to only use FAT32-formatted drives
for working copies on my system. Then I can send archives to
anyone and they will extract properly on a Windows OS machine.
However, some subtle problem with files on an NTFS drive
is leading Subversion to conclude that files have been changed
when in fact an external diff program shows that not one byte has changed.

I have placed a small repository on my server that is
about 40 KB in size and involves a few directories and
files. It can be checked out at :


if anyone wants to try to duplicate this strange result.
This repository is world readable.



To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 21 00:00:34 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.