Re: Sharing Common Files

[Todd Denniston]

Matt Doar wrote:
> 
> Perhaps this is belabouring the obvious, but soft links within
> repositories are not versioned, so when you want to change where the
> link points to in a few months from now, you won't be able to build the
> older versions of your product.
> 
I meant to indicate that these were in the SANDBOX but missed doing it
before hitting send.
Jim is correct though, if someone does a 
'cvs add SANDBOX/proj_2_tree/dir1/file1; cvs commit`
cvs will blithely add and commit the contents to a new place in the
repository and ignore the original in SANDBOX/proj_2_tree/proj_1_tree/ IIRC.
If I HAD to do what this guy was asking I would probably put a target in my
Makefile to make sure it was always a softlink... we are talking procedures,
knowledge and the ability of your workers to follow the procedures using the
knowledge.
The better route would be to make proj_1_tree a sub module of proj_2_tree
and have your build system use the file relative to the build position,
i.e.,  in SANDBOX/proj_2_tree/dir1/needsfile1.c
put the following line
#include <../proj_1_tree/file1.h> 
and put the appropriate things in your link line. plus have the build
program in SANDBOX/proj_2_tree/ build all the things needed in the
proj_1_tree/

> So regardless of whether you are linking to files or directories, server
> side soft links are not a good idea. A client side script to recreate
> them can be versioned.

client side is what I had meant.  but it is still not the best way.

> Modules are not versioned either, though I think
> there was a patch to do this a few months ago, but you can define new
> modules and still preserve the older ones.
> 
> ~Matt
> 
> > -----Original Message-----
> > From: address@hidden
> > [mailto:address@hidden
> > On Behalf Of Jim.Hyslop
> > Sent: Monday, January 31, 2005 8:25 AM
> > To: 'Todd Denniston'; Dean Do
> > Cc: address@hidden
> > Subject: RE: Sharing Common Files
> >
> > Todd Denniston wrote:
> > > assuming unix,
> > > in proj_2_tree
> > > |
> > > |- dir1
> > >     |- file1 softlink to ../proj_1_tree/file1
> > > |- dir2
> > >     |- file2 softlink to ../proj_1_tree/file2
> > >     |- file3 softlink to ../proj_1_tree/file3
> > > |- proj_1_tree
> > >    |
> > >    |- file1
> > >    |- file2
> > >    |- file3
> > Is "soft link" the same as a "symlink?" If they are
> > different, then the rest
> > of this message _might_ not apply.
> >
> > If they are the same, then this is a Really Bad Idea. The
> > problem is, CVS
> > sees dir1/file1 and proj_1_tree/file1 as completely separate,
> > independent
> > files. If user A is checking into dir1, then CVS will not
> > lock proj_1_tree.
> > This means that user B can simultaneously check in changes
> > into proj_1_tree
> > - leading to... shall we say, all kinds of fun.
> >
> > Bottom line: symlinks, if used at all, should _only_ be used for
> > directories, not for files.
> >

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter