Re: /#cvs.lock): No such file or directoryctory for <somedirectory inrepository>

[Todd Denniston]

Frederic Brehm wrote:
>
Note that I second Fred's suggestion of branches for the way you work.
 
> At 05:37 AM 8/18/2004, Jim Page - emailsystems.com wrote:
> >I think I have expressed myself badly. Our developers are working on both
> >windows and linux -at the same time-. Either with 2 dev boxes, or using
> >VMware to run the other OS, with a partition shared between the 2. What is
> >being suggested here is using commit to propogate changes between a given
> >developer's OS-specific sandboxes during development. I am talking here
> >about 'ok that fix builds under windows, lets see if builds under linux'. 

You could still use one sand box here, if you follow the next suggestion:
checkout on OS1
ONLY edit on OS1
build on both OSes
ONLY edit on OS1
ONLY update on OS1
build on both OSes
ONLY edit on OS1
ONLY update on OS1
ONLY checkin on OS1

That is, have the developer pick the OS where 1) they are comfortable with the
tools & 2) the file system is native[1], this OS is where the developer does
all h[er|is] cvs calls and editing (OS1 for that developer).
But it relies on the developer not forgetting that they can only build and
test on OS2, separate sandboxes using branches makes it more difficult to mess
that up.

[1] smb is native to windows but only really from another windows box.
nfs is native to unix, smb is not really native to unix.

> >In
> >our case right now this class of commit would not be done, and I can't see
> >how this won't lead to an increased risk of nonsense in the repository.
> >Maybe I'm splitting hairs but even if the risk is small it just doesn't seem
> >a good idea. I can't believe our situation is all that rare.
> 
> You might consider using branches. Make the commits on the branches, test,
> then if everything works correctly you can merge to the trunk. That way,
> the trunk has a high probability of not being broken.
> 
> Yes, this has more steps. However, you are working in a more complicated
> environment than usual so you shouldn't be surprised by extra complexity in
> the development process.
> 
> Fred
> 

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