>--- Forwarded mail from [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
