Re: Crazy idea - replace RCS backend with ClearCase...!!!

[Paul Sander]

Within a CVS context, I can see ClearCase triggers on checkout losing some
of their semantics.  That's because a "cvs checkout" is really a copy, and
a commit involves both a checkout and a checkin on the back end.  'Course,
you could treat CVS workspaces like snapshot views, and you would already have
a suitable process in place if your shop supports them.

My other concern is that things like "cvs add", "cvs rm", and "cvs update"
will not behave in the CVS way if you shoehorn ClearCase in as the back end
when the source tree changes shape.  You can try to hack in meaningful
behavior like Visual Source Safe does with regard to adding files (check out
the directory, add the file, check in the directory), but it's really not a
satisfying experience if you change your mind and never commit the file.

--- Forwarded mail from address@hidden

Hadn't really considered triggers.

I figure they should still fire - after all they were
put there to keep the vob consistent - that is not a
constraint that suddenly disappears because I access
it through a different interface... - is it ? How are
you using triggers that would not map to this ?

Re your other mail about CC's fnality being a superset
of CVS'. It doesn't worry me. I simply want CVS based
tools to work. If you need the extra fnality, you
simply step outside CVS and talk in CC instead.

--- End of forwarded message from address@hidden