RE: [oic] test documents - Symbolic Links? - POST MORTEM

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Bart,

I share your conclusion.  We shall not use symbolic links in working copies
of material intended to be synchronized with the OIC SVN repository.

It is clear that SVN does not preserve the linkiness of symbolic links (and
certainly "hard" links) as part of an SVN Commit, simply transferring the
text of the symbolic link entry to the SVN Server repository.  [This
suggests to me that symbolic links are not implemented in the file system
directly but via some wrapper mechanism in some *nix overlay.]

I am not sure what happens on a round trip update, even to the working copy
that had links in the first place, but it is clear that the SVN Repository
and any other system that makes an SVN Update or initial copy of a working
copy is only going to get what SVN has.

Perhaps the most serious aspect of having link information in the SVN
repository is how this makes the web interface to the SVN repository
unusable.  I think that has links be completely inappropriate with regard to
the web access that should be workable.    

 - Dennis

PS: I think NTFS has had links for a considerable time, probably at least
since Win32 and probably Windows 2000 for sure.  Whether they were easy to
exercise is a different matter, but I believe the POSIX subsystem could and
does recognize and allow them.  This is a speculation, which I could resolve
by installing the Subsystem for Unix (SFU) on my Windows XP system, but not
this year [;<).  I do mean to do that while I still have an XP system.  I
suspect that it could be made to work via a VM Unix installation too.  I
shall ask around.  I think 2010 is my year for Quad core hardware and a
machine that can run the Windows 7 VM feature to full effect.  I can't run
and test enough different implementations of ODF and OOXML otherwise [;<).
[Quick check: Opening the C Shell of the Windows 7 Subsystem for UNIX-based
Applications (SUA), I see that "man ls" lists --almost-all, --dereference,
and --classify options that involve symbolic links.]

PPS: Although even farther afield is the impact that links have on the
access-control-list and security/privacy support on a file system.  It is
clearly wise that SVN doesn't attempt to mirror any of that as well.

PPPS: Coming back a little closer to the situation at hand, there is also an
impact in the fact that my working sets are on a SOHO shared-file-server
running Windows Home Server, an overlay on Windows Server 2003.  This
overlay automatically replicates the directory that has my SVN working
folder (and all other OASIS-related materials) in a way where it is
recoverable even if I lose one of my two 500GB hard drives.  TortoiseSVN on
my client works happily with directories on the server, being completely
ignorant of the replication activity.  Although SFA can be activated on
Windows Server 2003, I would never do that for fear of messing up the WHS
overlay functionality.

P4S: There is a tangential relationship of this conversation with regard to
ODF 1.2 Packaging and what "folders" are any connection real- or imagined-
there is between ODF Package and any file-system structure whatsoever, along
with the fact that ODF 1.x allows URIs from package content files that may
go relatively into the filesystem where the package resides.  There are
myriad ways to break interop by presuming too much about that connection
(and certainly by making references to other material in a containing file
system).

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
http://lists.oasis-open.org/archives/oic/200912/msg00028.html
Sent: Thursday, December 10, 2009 03:37
To: dennis.hamilton@acm.org; oic@lists.oasis-open.org
Subject: RE: [oic] test documents - Symbolic Links? - EMPIRICAL RESULTS

Dennis,


thanks for the testing.

Now, Windows shortcuts aren't links, although ntfs does offer 'real' links
using
mklink on Vista and 7, but as demonstrated, SVN might not be able to use it
directly, and (for now) SVN lacks the share file feature of VSS :/

So, I'll rework the lot and make it more SVN-friendly, without the symbolic
links.

(not sure if Mac supports links, but this being and ODF test, not an file
system
/ OS interop test, I'm not inclined to have that one tested as well :-)


Best regards

Bart

________________________________________
From: Dennis E. Hamilton [dennis.hamilton@acm.org]
http://lists.oasis-open.org/archives/oic/200912/msg00027.html
Sent: Wednesday, December 09, 2009 8:12 PM
To: Hanssens Bart; oic@lists.oasis-open.org
Subject: RE: [oic] test documents - Symbolic Links? - EMPIRICAL RESULTS

I was going to be cute and make a Windows shortcut in place of the link
file, then see what SVN would do with that when I did a SVN Commit, and then
what would happen for you when you were to do an SVN Update.

Unfortunately, I can't do that.

I can't do that because the link (below) is not over a path that exists from
that place in my working tree.  And I get everything that the OIC SVN Server
has.  It appears that the packages file is meant to be a directory, but on
SVN and on my computer it is none of those, it is a file with a link in it.

So there appear to be even more problems with this approach.

 - Dennis


-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
http://lists.oasis-open.org/archives/oic/200912/msg00026.html
Sent: Wednesday, December 09, 2009 10:14
To: 'Hanssens Bart'; oic@lists.oasis-open.org
Subject: RE: [oic] test documents - Symbolic Links? - EMPIRICAL RESULTS

When I did an SVN Update on the OIC SVN Repository to my working copy (kept
on a shared server of my SOHO LAN), I get a file wherever you have made
links.  However, it was not the content of the shared file, it is the text
of the "symbolic link".

For example, the file

<http://tools.oasis-open.org/version-control/svn/oic/TestSuite/branches/bart
h/odf12/scenarios/part3/3/1/001.odt>

ends up on my machine with the name 001.odt and the OpenDocument icon.
However, it is a 41-byte text file with content

link ../../packages/preview_image/001.odt

Of course, the SVN server tries to serve it up as an ODT file too (or at
least my browser wants the DLL for resolving ODF file extensions).

To see what SVN has, go to
<http://tools.oasis-open.org/version-control/svn/oic/TestSuite/branches/bart
h/odf12/scenarios/part3/3/1/>

and download rather than open the 001.odt (or the layout.css for that
matter).

This strikes me as the worst of all possible results.  I speculated
something that would be correct but confusing on your system if anyone else
did updates.  This is worse.   (In VSS, which I still use for development
web-site server source control, I can and do solve this by *actually*
sharing files across projects/folders and a change to any shared copy would
be reflected in new checkouts/gets of any of the others.  I also do this
with software projects that rely on libraries built in other projects under
the same VSS. But VSS is gone forever and no other SCC system seems to have
that feature.)

I don't know what would happen if a Windows shortcut file were used in place
of one of these.  I don't think this provides the desired behavior, in any
case.

[ ... ]