>--- Forwarded mail from [EMAIL PROTECTED]
>Are there any gotchas in adding symbolic links to a CVS repository
>file structure? I'm trying to set up cvs for Java development, and
>I'd like a structure like the following:
>REPOSITORY:
> core/com/purpletech/util/
> Utils.java,v
> projects/NiceApplet/
> NiceApplet.java,v
> @com/ -> symbolic link to core/com
> projects/NiceServlet/
> NiceServlet.java,v
> @com/ -> symbolic link to core/com
>WORKSPACE:
> projects/NiceApplet/
> NiceApplet.java
> projects/NiceApplet/com/purpletech/util/
> Utils.java
> CVS/Root = "projects/NiceApplet/com/purpletech/util"
> projects/NiceServlet/
> NiceServlet.java
> projects/NiceServlet/com/purpletech/util/
> Utils.java
> CVS/Root = "projects/NiceServlet/com/purpletech/util"
>Will cvs freak out if the same directory/,v files are commited or
>locked by users accessing them from different symbolic link
>directories? (Different Root, same ,v)
It will probably work, but using symlinks in the repository is strongly
discouraged because the aliasing effect they have is confusing and may even
be detrimental in the future. You're better off using the modules database
to map the workspace to the repository correctly.
Try this to see if it solves your problem:
applet-only projects/NiceApplet
applet-comm -d projects/NiceApplet/com core/com
NiceApplet -a applet-only applet-comm
servlet-only projects/NiceServlet
servlet-com -d projects/NiceServlet/com core/com
NiceServlet -a servlet-only servlet-com
One of the benefits of using this mechanism is that you have the ability
(however awkward) to reorganize your projects around the module boundaries
without giving up reproducibility of your process. This is a capability
that is not afforded you by using symlinks. It also offers you the
ability to constrain the amount of the core/com tree you wish to include
in your sandboxes in the event that more com components are added in the
future.
>--- End of forwarded message from [EMAIL PROTECTED]
