[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /#cvs.lock): No such file or directoryctory for <some directory inre

From: Doug Lee
Subject: Re: /#cvs.lock): No such file or directoryctory for <some directory inrepository>
Date: Tue, 17 Aug 2004 19:52:32 -0400
User-agent: Mutt/1.5.6i

On Wed, Aug 18, 2004 at 12:24:31AM +0200, Jim Page - wrote:
> From: "Todd Denniston" <address@hidden>
> > Huge suggestion:
> > Read the messages found here:
> >
> >
> >
> Thanks for the suggestion, very interesting reading.
> In my case the repository is on a linux box accessed via :ext: CVS_RSH=ssh.
> >From what I have read this is not a bad method. So I do not have problems
> with the repository accessed as a shared local drive as in some of the
> postings above.
> > Always use a client that is native to the host you are doing your editing
> on!
> > Never share directories between different OS's, do a full checkout on the
> > host/OS you are doing the editing on, as some OS's will not use the same
> line
> > endings.
> What you are suggesting, and is also suggested in the above postings, is
> having 2 sandboxes, 1 linux and 1 windows, right? Ok but it sounds like a
> typical case of us working round the tools rather than them working for us.

Actually, since line endings are different between Windows and Linux,
I don't see how you could safely do any different:  If you edit in
Windows and Alice edits in Linux and you share a directory, chances
are extremely high that Alice will introduce lines with missing CR's
and you'll introduce lines with extra CR characters.  To me, it's a
bit like this:  If you check out in English and she checks out in
Spanish, you can't really use the same checkout without getting
gibberish. <grin>

> But I get the feeling that is the recommended way - commit/update, often.

How often you commit here is no different than how often two
developers with their own sandboxes commit in any other scenario.  You
only have to commit often if you both have to see the absolute latest
updates from each other all the time.  That's true no matter where
your sandboxes are and no matter what format they're in.

> Hmm. Committing something to a repository just in order to get it into the
> other sandbox sounds all wrong to me. As a common sense approach to version
> control, I try to get my people to a) not commit anything unless they are
> pretty sure it builds and works, b) put meaningful comments in the logs.
> This 2-sandbox strategy is going to mess that up for sure! If everybody is
> doing loads of commit/updates to copy between sandboxes during development,
> then there is an excellent chance that Alice picks up Brian's half-baked
> commit and that's him/her out of play trying to figure out what they just
> busted.

Unless I'm missing something huge, no.  Communication between
developers should be able to remain the same, even if some are using
Linux and some are using Windows.

> Getting this surely very common scenario to work reliably with a shared
> directory would certainly go on my wish list. Specially since it -nearly-
> works ... no corruption of data as far as I can tell, just a weird error
> message.  While we are talking about it, what it the point in being able to
> specify what kind of line endings you want when you check stuff out, if it
> isn't followed through?

I'm not sure what you mean here by "not followed through."  The line
ending convention is set by which OS you use to make a checkout, and
it's followed religiously within that environment.  It's only when you
start mixing OSes in the same sandbox that you get a lot of weird
mixtures of line endings everywhere.

> But hey ... if a cvs guru says don't go there, it will never work, then I
> will look at the alternatives, and thank him for the advice. But it seems to
> me a surprising weakness in cvs from the POV of cross platform development.

I find CVS's handling of line endings a definite strength:  It allows
me to have a single master copy of a project that I can work on in
multiple OSes without ever having files show up in the wrong format
for the environment I'm using at any given time.  I can work on a
Windows project in the office but then get a call while I'm on the
road somewhere and connect to a Unix box, check out the project in
Unix, make an update, give it a fine log message (<grin>), chec it in,
tell the caller to do an update in Windows, and know that even though
I just did source code modification in an LF-only environment,
everything will magically come out with proper CR/LF endings for
Windows back at the office, and the caller will be happy--at least if
I fixed the problem...

> Cheers
> Jim
> ------------------------------------------------------------------------------------
> Email the way you want it - scanned for viruses and unwanted content by 
> emailsystems
> Information regarding this service can be found at
> _______________________________________________
> Info-cvs mailing list
> address@hidden

Doug Lee           address@hidden
Bartimaeus Group   address@hidden
"Believe, when you are most unhappy, that there is something for you
to do in the world. So long as you can sweeten another's pain, life is
not in vain."
--Helen Keller

reply via email to

[Prev in Thread] Current Thread [Next in Thread]