subversion can't commit project under symlink?

[Steve Lefevre]

I have  a subversion project checked out in a directory. I created a symlink name for the directory, and svn seems to behave differently depending on whether I reference the project by the real directory name, or the symlink. The symlink works okay for commands like "status" and "add", but it fails on "commit"! ( Using the real directory name works for all commands, at least the ones that I've used. ) I'm using version 1.4.2.

Here is the symlink directory working just like the real directory when I add files and ask its status:

$> svn status real_directory/
A      real_directory/new_file.txt
$> ln -s real_directory/ symlink
$> svn status symlink
A      symlink/new_file.txt
$> svn status real_directory/
A      real_directory/new_file.txt
$> touch symlink/another_new_file.txt
$> svn status symlink
?      symlink/another_new_file.txt
A      symlink/new_file.txt
$> svn add symlink/another_new_file.txt
A         symlink/another_new_file.txt
$> svn status symlink/
A      symlink/another_new_file.txt
A      symlink/new_file.txt

However, this symlink directory fails on the commit command:

$> svn commit symlink/ -m "test commit"
svn: '/home/restcon' is not a working copy
svn: Can't open file '/home/restcon/.svn/entries': No such file or directory

Huh? That's weird. Svn certainly thinks that file exists when I do status and add! Maybe it got deleted?

$> ls symlink/.svn/entries
symlink/.svn/entries

Nope, still there. Does it still have data in it?

$> ls -lha !$
ls -lha symlink/.svn/entries
-r--r--r-- 1 user group 14K 2009-12-18 06:36 symlink/.svn/entries

Yup, seems to be okay! Alright, forget trying to commit the directory by its symlink. What about just committing the directory by its real name?

$> svn commit real_directory/ -m "test commit"
Adding         real_directory/another_new_file.txt
Adding         real_directory/new_file.txt
Transmitting file data ..
Committed revision 1144.

Works fine. Why does svn work with add and status on a symlinked directory, but not commit?

[Rob van Oostrum]

On Fri, Dec 18, 2009 at 1:36 PM, Steve Lefevre <slef...@restcon.net> wrote:

>
> Looks like real_directory is the the top of your working copy, is this
> correct?

If I understand you right, that's true. It has the .svn directory.

>
> If so, what seems to be happening is that SVN (which is capable of
> version-controlling symbolic links), is trying to commit your symbolic link,

Oh, I see! Since a symbolic link is a filesystem file, svn thinks I'm tyring to commit *that symlink as a file* for a project in the current directory!

> but the directory the link is in (/home/restcon) is not an SVN working copy
> directory, so the commit fails right away.
>
> Try to run 'svn commit symlink/*', which should work just fine.

That works!

Should I file this as a bug report? It seems to me that svn should be smart enough to figure this out -- although, that would take some thinking.  Svn is able to handle other operations intuitively, such as status.

No, this isn't a bug IMO. SVN is designed to support versioning symbolic links. Committing changes to/under it is a scenario where it has to break directory/link transparency because it's ambiguous what you're telling the client to do (i.e. creating the symbolic link vs. committing the changes in the location the new link is pointing to).

- Rob

PS - Took this off-list accidentally. Back now.

[Steve Lefevre]

On 12/18/2009 1:41 PM, Rob van Oostrum wrote:

Should I file this as a bug report? It seems to me that svn should be smart enough to figure this out -- although, that would take some thinking.  Svn is able to handle other operations intuitively, such as status.

No, this isn't a bug IMO. SVN is designed to support versioning symbolic links. Committing changes to/under it is a scenario where it has to break directory/link transparency because it's ambiguous what you're telling the client to do (i.e. creating the symbolic link vs. committing the changes in the location the new link is pointing to).

Well, let me argue the point a bit.

You would never create a symbolic link with a commit statement, right? You could only do it using add? If I make a symbolic link, and try to commit it, I get a "not under version control" error.

In other words, the flow control that svn would need when it sees "svn commit symbolic_link" is

if already_in_project_directory && symbolic_link_is_under_version_control
    commit normally
else if
    check if the symbolic link is itself a subversion project, and commit it
else
   fail with warning.

In other words, I'm already getting an error that the file isn't under version control -- there's no ambiguity. Why not at that point do an additional check to see if I'm wanting to commit a subversion project contained within a symbolic link to a directory, before failing?

Or maybe I'm not understanding -- can you give an example of the scenario where the ambiguity arises?

-- 
Steve Lefevre
Lead Developer
Restaurant Consultants, Inc.
( 614 ) 421-1441
slef...@restcon.net

[Rob van Oostrum]

No, the error you're getting is that the parent directory of what you're telling the client to commit is not a working copy. You can't commit a symbolic link to SVN unless it lives inside a working copy, which in your example it doesn't.

Telling the client to commit a symbolic link is fundamentally different from telling it to recursively commit changes to a directory, which is why the client behaves differently in each of these scenarios.

-Rob

[Steve Lefevre]

On 12/18/2009 2:06 PM, Rob van Oostrum wrote:
>
> No, the error you're getting is that the parent directory of what
> you're telling the client to commit is not a working copy. You can't
> commit a symbolic link to SVN unless it lives inside a working copy,
> which in your example it doesn't.

This is correct, I was mistaken. But why don't I get that same error,
then, when I do "status" or "update"? It's inconsistent.

>
> Telling the client to commit a symbolic link is fundamentally
> different from telling it to recursively commit changes to a
> directory, which is why the client behaves differently in each of
> these scenarios.

Right, giving those exact commands are fundamentally different, but what
I was trying to *express* was "commit the changes recursively under the
directory referenced by this symlink" -- and we know this.

What I'm arguing is that with a little additional decision-making, svn
could know what I was trying to express, and then you get consistent
behavior. Otherwise, why shouldn't svn give me the same error when I do
"status" or "update" on the symbolic link? It's smart enough to
'traverse' the symbolic link in those cases -- it seems to me that it
could also do this for "commit". The behavior is counter-intuitive: in
the cases of "status" and "update", it figures out that the symlink
points to a project and that I'm not referring to the current working
directory as a project, but then with commit ( and probably other
command ) it suddenly seems to "forget" that it links to a project,
whereas it knew it before. The human-facing interface is inconsistent.

I don't see the case where ambiguity would arise -- could you give an
example, please?

Steve

--
Steve Lefevre
Lead Developer
Restaurant Consultants, Inc.
( 614 ) 421-1441
slef...@restcon.net

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2431572

Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-s...@subversion.apache.org>.