AW: Hard links on Win2k/XP

[Marco Scholz <ms...@samson.de>]

>> [...] I would say that the problem is, that 
>> subversion overwrites files in an unusual way. [...]
>
>Definitely not. There is nothing unusual about it, and it's the right 
>way to go.
>
>Just because other programs fail to do it properly is no reason to 
>follow suit.
>
>I suggest you find another way of doing what you intended with the link, 
>whatever that was. Still puzzling about that.


I'm not saying that the copy,delete,rename scheme is bad. I has clearly it
advantages. But it has some side effects. I'm not talking about changing the
default behaviour of subversion (!), just a switch or setting to modify it.

I'm trying to solve the following situation:

For example I have a file called file1.xml.

This file is used by some applications we are developing. So it has to be in
the following directories:

Path1\file1.xml
Path2\file1.xml
Path3\file1.xml
Path4\file1.xml
...

If I modify the xml file on one location, I want that all copies of the file
will be modified as well. And I want to have the file under version control
of subversion.

My idea was to link the files on Path2,Path3,Path4... with hard links to the
real file in Path1 and only put one file  (Path1\file1.xml) under version
control.

By the way, this situation only occurs on our development computers, not on
customers' side, because there we can distribute the file with the every
application again.

Our current solution for this problem is a tool that is monitoring file
changes and ensures that all versions of the file always stay the same. But
this tool costs a lot of disk performance, so we are looking for a more
smart solution.





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: AW: Hard links on Win2k/XP

[Klaus Rennecke <kr...@tigris.org>]

Marco Scholz wrote:
> [...]
> I'm trying to solve the following situation:
> 
> For example I have a file called file1.xml.
> 
> This file is used by some applications we are developing. So it has to be in
> the following directories:
> 
> Path1\file1.xml
> Path2\file1.xml
> Path3\file1.xml
> Path4\file1.xml
> ...
> 
> If I modify the xml file on one location, I want that all copies of the file
> will be modified as well. And I want to have the file under version control
> of subversion.

Well, the most simple and general way to access the same file from 
several locations is to use its file name. If Path1-Path4 are always 
structured the same way in relation to each other, you could, for 
example, locate the file1.xml in Includes\file1.xml and access it there 
from the projects as ..\Includes\file1.xml.

Yes, this sounds trivial, but more often than not I see complex 
solutions around this case where a simple relative path would have done 
the job.

If the Path1-Path4 are not always in the same location relative to each 
other, or other tools require that the file is below the PathX 
directory, the svn:externals may help you out here. However, this only 
allows addressing complete directories, not single files. *That* is a 
limitation of svn that I would like to see lifted, but it does not seem 
to be easy to do that :-)

     http://svnbook.red-bean.com/svnbook/ch07s03.html

> My idea was to link the files on Path2,Path3,Path4... with hard links to the
> real file in Path1 and only put one file  (Path1\file1.xml) under version
> control. [...]

Hard links tend to get you into all sorts of trouble and side-effects. 
This is not subversion specific. Backup tools and archivers are prone to 
be confused by hard links. They might even understand hard links but 
handle them in a way you don't expect. Evaluating all tools possibly 
required to see if hard links work ok is usually not worthwhile.

Greetings from Berlin,
/Klaus

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org