Version 1.7 and symlinks

[AcesHidden]

So, I guess I have a "special" setup. I am using symlinks on my Windows Vista x64 box so that my VS projects can use "shared resources".

This works great with 1.6x however stops working completely in version 1.7x It wants to commit these folders as there are no longer .svn folders in each sub-folder.

So I guess the moral of the story is, if you are using symlinks and don't want to check them in more than one place, which wouldn't work anyways, DO NOT UPGRADE TO VERSION 1.7x.

Please fix this!!!

If anybody has a work around, I would love to hear about it. I doubt it though from my understanding of how 1.7x works.

[andyl]

NTFS didn't get true symlinks until Windows Vista, so to maintain compatibility with older releases of Windows, Subversion would likely not support them yet. Also, APR (which Subversion depends upon) doesn't support them yet as far as I know.

Can you use svn:externals instead of symlinks?

[AcesHidden]

I am running Windows 7. The way they were "supported" before the change to 1.7x worked perfectly as the symlink pointed to a folder, that had a .svn folder within it so it knew where it really was.

Now that the new version has a .snv folder only in the root folder that contains the database it no longer works as it wants to check in the "new" folders and files it sees that aren't part of that repository/folder.

Basically my set up is this:

Trunk
-----> CommonResources
---------> Collection of folders and files that are used across US and UK
-----> US
---------> Folders and symlinks to folders in CommonResources
-----> UK
---------> Folders and symlinks to folders in CommonResources

With the older version of tortoise this worked just fine.

I am looking into svn:externals now but it looks like it definitely won't be even remotely as convenient as the set up I have now.

For now, I have reverted to 1.6x.

[AcesHidden]

Reading this paragraph makes me think that using svn:externals is not a good idea:

Also, since the definitions themselves use absolute URLs, moving or copying a directory to which they are attached will not affect what gets checked out as an external (though the relative local target subdirectory will, of course, move with renamed directory). This can be confusing—even frustrating—in certain situations. For example, if you use externals definitions on a directory in your /trunk development line which point to other areas of that same line, and then you use svn copy to branch that line to some new location /branches/my-branch, the externals definitions on items in your new branch will still refer to versioned resources in /trunk. Also, be aware that if you need to re-parent your working copy (using svn switch --relocate), externals definitions will not also be re-parented.

What I am understanding from that is if you branch that the externals will still point to trunk from within the branch. That would seem like a nightmare to manage for each branch when branching and reintegrating.

[andyl]

I believe there are scripts you can use in copying (branching) which will update the externals definitions to track properly with the branch.

[andyl]

I am running Windows 7. The way they were "supported" before the change to 1.7x worked perfectly as the symlink pointed to a folder, that had a .svn folder within it so it knew where it really was.

Now that the new version has a .snv folder only in the root folder that contains the database it no longer works as it wants to check in the "new" folders and files it sees that aren't part of that repository/folder.

Well, it "worked" in the past only because of unintended consequences/side-effects of how Subversion managed its WC metadata. You took advantage of undocumented/unsupported/accidental functionality, and when something changed which didn't take into account your (very unorthodox) setup, you got burned.

If you're going to stay with your current setup, you will be stuck with Subversion 1.6 forever (unless externals are overhauled to be more convenient for you).

[AcesHidden]

LOL, yeah I know. It was quite a painful process finding a working solution for what I was trying to accomplish with Visual Studio and shared resources. I guess I got lucky that Tortoise worked the way it did at the time.

I will look into the scripts you mentioned at a later time. Unfortunately I just do not have time to overhaul the way branching and the shared resources work right now and I figured that I could save someone else the hassle if by chance they are using a similar setup.

Thank you for the quick replies.