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

RE: RE: Symlinks on Win32...

From: Duke Tantiprasut <duke_at_resolve-systems.com>
Date: 2006-01-31 20:37:45 CET

My thoughts on the following cases (see below):

> -----Original Message-----
> From: Mark Phippard [mailto:markp@softlanding.com]
> Sent: Tuesday, January 31, 2006 10:58 AM
> To: Gale, David
> Cc: Duke Tantiprasut; users@subversion.tigris.org
> Subject: RE: RE: Symlinks on Win32...
>
> "Gale, David" <David.Gale@Hypertherm.com> wrote on 01/31/2006
> 01:39:18 PM:
>
> > I'd second this idea.
> >
> > Given:
> >
> > /foo
> > - file1
> > /bar
> >
> > svn link svn://example.com/foo/file1 svn://example.com/bar/file2
> >
> > Should produce:
> > /foo
> > - file1
> > /bar
> > - file2
> >
> > At which point, the following should be true:
> > svn co svn://example.com/
> > cd bar
> > <change file2>
> > svn ci
> > cd ../foo
> > svn stat -u
> > U file1
> >
> >
> > Any other design thoughts? Any votes against, or shall we
> pass this
> > on to the dev list?
>
> I wouldn't say that I am against it, but I think there are so
> many edge cases to consider that you have little chance of
> ever seeing someone try to implement it.
>
>
> I wouldn't say that I am against it, but I think there are so
> many edge cases to consider that you have little chance of
> ever seeing someone try to implement it.
>
> First off, let me just say that your example does a nice job
> of expressing what you see as the requirements. But let's be
> realistic here. Once your repository is materialized into a
> working copy you have to start dealing with the realities and
> limitations of the local file system. In your example, how
> do you see the working copy code being able to see file1 as
> having been changed, when it hasn't been?

DUKE> Both working copies of /foo/file1 and /bar/file2 is compared with the
respository /foo/file1. If the working copy of /bar/file2 is changed and
checked in, it updates /foo/file1. The repository /bar/file2 is simply a
link.

>
> Now for a few quick edge cases:
>
> What if file1 and file2 are both modified in the working copy?

DUKE> The working copy is just a "copy" and NOT a symlink on the file
systems. If the working copy of /foo/file1 is changed, the working copy of
/bar/file2 is completely unaware until file1 is checked in and file2 tries
to check in. Think of it as 2 users working on the same repository file but
in this case the two users are the same user and the repository file2 is a
symlink to repository file1.

>
> What does svn delete of one of the files do? What if one is
> changed and the other deleted?

DUKE> delete on the link (i.e. svn://../bar/file2) removes the link. It does
not remove the original file. If you remove the original file, all symlinks
are also removed.

I think to start of it may be easier to restrict symlinks to just
directories. This would be similar svn:externals but would also allows
changes to contents (files, properties, etc) in the symlinked directory to
be check in and update the originals. I think svn:externals are fine for
external repositories, but for local references, it shouldnt be so limited.

Duke

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 31 20:39:04 2006

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.