RE: Hard Links

[Paul Sander]

>--- Forwarded mail from address@hidden

>       I will explain:
>1) I have 2 directories inside CVSROOT with different names A and B.
>2) I have a1,a2 files in A directory
>3) I have b1,b2 files in B directory 
>4) I want that if i modify file a1, b1 should be modified automatically and
>vice versa
>5) If i will modify a2, b2 would be modified automatically  and vice versa

>I don't  want to modify the module defination to checkout coomon file from
>one common location for both these projects As file names a1,b1 are
>different and same is the case for a2,be but files are exactly copies of
>each other I can attain this functionality by doing soft links in Linux and
>can modify the files in wincvs to get my results but not through hard links

Have you actually succeeded, using this method, to keep the RCS files
identical?  I think that the first time you commit a change via the
symlink you'll find yourself with two RCS files and your changes will
begin to diverge.  The reason for this is the way the RCS file locking
protocol works:  Create a lock file, copy the RCS file to the lock file,
merge the change into the lock files, then rename the lock file back to
the RCS file.  The last time I read the RCS source code, it didn't
chase symlinks to their definitive sources and apply changes there; it
treated symlinks like files.  So when you commit via the symlink, the
lock file is created where the symlink is, then the modified RCS file
replaces the symlink.  By the way, this applies to all operations that
modify the RCS file, including tagging and changing keyword expansion.

The other problem is that CVS adds a directory level locking protocol
to keep the RCS files static while a group of them are updated.  Using
symlinks to spoof RCS files defeats this because a change to the true
source can spring a surprise if the symlink side has also been locked
and the update is delayed.  The RCS file locking protocol offers no
protection from this because the true source could have a new version
introduced while the symlink side thinks it's up to date.

If you plan to continue using CVS, you'll be way better off refactoring
your project so that there's just one true source for these files.  If
that simply is not possible, then you'll have to adopt a discipline in
which you never commit or tag via the symlink; in other words, choose the
one true source and modify that, and perform only checkouts and updates on
the other side.

>One More Question:
>As mentioned by you linking files, you
>have defeated CVS's locking system and you're asking for a corrupted
>repository.  Soft linking directories isn't dangerous

>Could you please suggest me more on this

The CVS locking mechanisms work on a directory basis, and symlinks to
directories within the repository don't affect them.  So if you want
to have a directory appear in several places (without doing module
file calisthenics) then this is a way to do it.  But the contents
of each instance are obviously identical.

>--- End of forwarded message from address@hidden