How to convert a regular file to a sym link?

[Matt England]

I have files under svn control that we converted from a regular file to a soft link (as per ldconfig: http://www.die.net/doc/linux/man/man8/ldconfig.8.html ).

I want to force this change into subversion's control so that said file no longer comes up in a 'svn status' list.

Any suggestions?

The only thing I can think of right now is to 'svn revert', 'svn del', then 'svn add' the file after running my ldconfig (that creates the sym link) again. This seems rather cumbersome to do for every file.

Thanks for any help,
-Matt

[Matt England]

Post by Matt England
The only thing I can think of right now is to 'svn revert', 'svn del', then 'svn add' the file after running my ldconfig (that creates the sym link) again. This seems rather cumbersome to do for every file.

To be clear, all these files show up as:

# svn status
~ mylib.so.1.0
[...]

Thanks for any help. More details below.

-Matt

Post by Matt England
I have files under svn control that we converted from a regular file to a soft link (as per ldconfig: http://www.die.net/doc/linux/man/man8/ldconfig.8.html ).
I want to force this change into subversion's control so that said file no longer comes up in a 'svn status' list.
Any suggestions?
The only thing I can think of right now is to 'svn revert', 'svn del', then 'svn add' the file after running my ldconfig (that creates the sym link) again. This seems rather cumbersome to do for every file.
Thanks for any help,
-Matt
---------------------------------------------------------------------

[Saulius Grazulis]

Any more thoughts on this?  I need to solve this problem pretty soon, would

like to do this for all my files across the board in a more-elegant way then

Post by Matt England
The only thing I can think of right now is to 'svn revert', 'svn del',
then 'svn add' the file after running my ldconfig (that creates the sym
link) again.  This seems rather cumbersome to do for every file.

# svn status
~     mylib.so.1.0
[...]
Thanks for any help.  More details below.

I would try something like this (careful, commands untested! Dont run them as
root, check before!):

*nix> for i in `svn st | awk '/^~/{print $2}'`; do ( set -x; mv $i $i-old; svn
del $i; svn ci -m "Deleting $i" $i; mv $i-old $i; svn add $i; sv ci
"Committing new $i"; ) done

To check that the commands really do what you want, put 'true' or 'echo' in
front of every 'svn' and 'mv' command in the above example and run the
resulting command; when you see that it is going to do what you want, remove
'echo/trure' and run once more.

Hope this helps.
--
Dr. Saulius Gražulis

Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
LT-10306 Vilnius
Lietuva (Lithuania)

tel/fax: [phone]
mobilus: ([phone], ([phone]

[Matt England]

Hi Saulis,

Thanks for your response. Comments below.

Post by Saulius Grazulis

Any more thoughts on this? Â I need to solve this problem pretty soon, would

like to do this for all my files across the board in a more-elegant way then

Post by Matt England
The only thing I can think of right now is to 'svn revert', 'svn del',
then 'svn add' the file after running my ldconfig (that creates the sym
link) again. Â This seems rather cumbersome to do for every file.

I would try something like this (careful, commands untested! Dont run them as
*nix> for i in `svn st | awk '/^~/{print $2}'`; do ( set -x; mv $i $i-old; svn
del $i; svn ci -m "Deleting $i" $i; mv $i-old $i; svn add $i; sv ci
"Committing new $i"; ) done

Ok, so this looks like an automated means to do execute the manual process describe above, and that's a good thing.

However, I was hoping there was an alternative way to do this via subversion, at least on a per-file basis, other then the svn del-then-add process, chiefly because said process loses the file history properties (I think).

Any further thoughts?

In any case, thanks for the above automation code.

-Matt

[Noel Yap]

Post by Matt England
However, I was hoping there was an alternative way to do this via subversion, at least on a per-file basis, other then the svn del-then-add process, chiefly because said process loses the file history properties (I think).
Any further thoughts?

Like I said before, don't keep symlinks under version control.
Rather, version control a script that creates the symlinks. You'll
never lose history if you only version control files.

Noel

[Saulius Grazulis]

Post by Noel Yap

Post by Matt England
Any further thoughts?

Like I said before, don't keep symlinks under version control.

There is nothing bad in keeping symlinks under Subversion.

I use build systems that are extensively based on symlinks, and Subversion
handles my trees just fine. Actually, Subversion is the only VC system,
AFAIK, that handles symlinks nicely, and this is the main reason why I use
it ;)

Situations when links get converted to files and wice versa are, at least in
my practice, rare, and though unpleasant can by handled by shell automation.

Post by Noel Yap
Rather, version control a script that creates the symlinks.

Brrrr... This sounds like too much complication for me.

I use links exactly for the reason that they permit to express relations
between file easily; the necessity to handles those relations with scripts is
too cumbersome, for my taste.

Although, such system would be more flexible and would permit to use VCSes or
filesystems that do not support symlinks -- an advantage in some cases.

Post by Noel Yap
You'll
never lose history if you only version control files.

AFAIU, subversion keeps history of symlinks as well, doesn't it?
--
Dr. Saulius Grazulis

Institute of Biotechnology
Graiciuno 8
LT-02241 Vilnius
Lietuva (Lithuania)

fax: [phone]
tel.: office: ([phone]
mobile: [phone]

[Kent Borg]

Judging from this thread Subversion is happy with symlinks, but does
anyone here have experience with getting svn_load_dirs to work with
symlinks?

I am trying to get an existing project into Subversion, and at the
moment I am stalled with svn_load_dirs refusing to deal with symlinks.
I fear Subversion isn't up to the job. Any help would be appreciated.

-kb

[Ryan Schmidt]

Post by Kent Borg
Judging from this thread Subversion is happy with symlinks, but does
anyone here have experience with getting svn_load_dirs to work with
symlinks?
I am trying to get an existing project into Subversion, and at the
moment I am stalled with svn_load_dirs refusing to deal with symlinks.
I fear Subversion isn't up to the job. Any help would be appreciated.

You must patch svn_load_dirs before it will support symlinks:

http://svn.haxx.se/dev/archive-2005-02/0611.shtml

See this bug report:

http://subversion.tigris.org/issues/show_bug.cgi?id=2241

[Toby Johnson]

Post by Matt England

Post by Saulius Grazulis
*nix> for i in `svn st | awk '/^~/{print $2}'`; do ( set -x; mv $i $i-old; svn
del $i; svn ci -m "Deleting $i" $i; mv $i-old $i; svn add $i; sv ci
"Committing new $i"; ) done

Ok, so this looks like an automated means to do execute the manual process describe above, and that's a good thing.
However, I was hoping there was an alternative way to do this via subversion, at least on a per-file basis, other then the svn del-then-add process, chiefly because said process loses the file history properties (I think).

Subversion stores symlinks as a regular text file containing what the
link points to, along with a special property, I believe "svn:special"
or something of the sort. Instead of a script to delete/recreate the
files, you could use one to set all those special properties.

But no, I don't think there's a way for Subversion to just do that
automatically. And by the way, when you place a symlink into Subversion,
you won't be able to view the contents or history of what that symlink
points to from within Subversion. So if the target file changes, you
won't be able to "svn log" the symlink and see those changes, for
example. Maybe knowing this will make preserving history seem less
important.

[Matt England]

And by the way, when you place a symlink into Subversion, you won't be able to view the contents or history of what that symlink points to from within Subversion. So if the target file changes, you won't be able to "svn log" the symlink and see those changes, for example. Maybe knowing this will make preserving history seem less important.

I want the history of the file name that represents the sym link (including the history of when it was *not* a sym link), not the thing that the sym link points to.

Does this not work?

-Matt

[Saulius Grazulis]

Post by Matt England

Post by Saulius Grazulis
I would try something like this (careful, commands untested! Dont run them
*nix> for i in `svn st | awk '/^~/{print $2}'`; do ( set -x; mv $i $i-old;
svn del $i; svn ci -m "Deleting $i" $i; mv $i-old $i; svn add $i; sv ci
"Committing new $i"; ) done

Ok, so this looks like an automated means to do execute the manual process
describe above, and that's a good thing.

Yep.

Post by Matt England
However, I was hoping there was an alternative way to do this via
subversion, at least on a per-file basis, other then the svn del-then-add
process, chiefly because said process loses the file history properties (I
think).

I am not aware the Subversion command that would do this.

Post by Matt England
Any further thoughts?

Are situation when file<->symlink conversion happens often in your case? If
so, what about writing svn-file-to-symlink script that accepts filenames as
arguments and runs the above procedure? Could be a generally usefull tool...

Since this problem can be (relatively easyly) solved by external means, and
the problem is, generally, rare, it would probably be an overkill to include
this functionality into Subversion directly, what you think?

Post by Matt England
In any case, thanks for the above automation code.

Don't mention :)

NB: I have spotted the bug there, the las command should read: "... sv ci
"Committing new $i" $i; ) done" (note the $i addition, so that only that one
file gets checked in, not the whole tree).
--
Dr. Saulius Grazulis

Institute of Biotechnology
Graiciuno 8
LT-02241 Vilnius
Lietuva (Lithuania)

fax: [phone]
tel.: office: ([phone]
mobile: [phone]