Re: Using network shares as sandboxes

[Eric Siegerman]

On Mon, Sep 17, 2001 at 10:30:50AM -0700, brent wrote:
> I have been informed that there are 'a thousand reasons' why
> not to use network shares as sandboxes with CVS.

The problem is different from the one with a remote-mounted repo,
where one risks repo corruption due to O/S bugs or similar
problems.  In the case of remote mounted sandboxes, the problem
is with line-endings getting messed up.

Client/server CVS deals with the issue using the standard pattern
-- a machine-independent protocol, with the client translating
to/from local conventions.  When you share a sandbox
cross-platform (as you're planning to do for those Linux
clients), it's very easy to screw up, and get strange stuff in
the repo (extra ^M's), or in the sandbox (missing ^M's in a
sandbox that needs them, because it's being used by a Windows
client).

It's *possible* to be careful, and always use the right CVS
client on the right sandbox -- indeed, users at my shop have done
it, though with occasional slipups requiring manual intervention.
But it's a lot easier to just avoid the problem, by avoiding
configurations that make it possible, i.e. avoiding
remote-mounted sandboxes.

> [...] but we wish to keep things on the network to make 
> it easy to communicate and share files between team members.

There's a big process problem here, and it has nothing to do with
where the sandboxes live.

The best way to share sandbox files is using CVS.  If people copy
files directly between sandboxes, they risk losing, or at least
misplacing, changes.  Suppose you and I are collaborating on
foo.c.  The repo is at rev. 1.2.
  - We both update to rev. 1.2 in our sandboxes.
  - Mary checks in 1.3.
  - You do a "cvs update"; I don't.
  - I make some change.  I don't commit it (because I'm not confident
    of it yet); instead I say, "hey Brent, try this out".
  - You copy foo.c from my sandbox to yours; you decide you like
    the change and commit it, creating rev. 1.4.

Rev. 1.4 does NOT contain the rev. 1.3 changes.  If I had tried
to commit my change, CVS would have forced me to do an update.
But because you were already up to date, the commit succeeded,
even though the file being committed was based on 1.2, not 1.3.

The better way would have been for me to commit the change (to a
branch if necessary), and for you to retrieve my change via CVS.

Yes, in the above example, the change is still there in the repo,
but:
  - Mary will be very confused when she next does an update and
    the bug she's *sure* she fixed reappears.  It may take her
    quite a while to realize that her changes got clobbered --
    and when she does, she's likely to be rather pissed off at
    *both* of us :-/
  - Trying to unscramble a situation like that can be
    time-consuming and frustrating, especially if many files are
    involved, and it's not noticed until many revisions later.
    (Trust me; I've spent several days at this kind of stuff this
    summer.  I can think of ways I'd rather spend my time...)
  - It would be just as easy to lose changes completely.  Suppose
    that, when you copied my foo.c into your sandbox, you had
    uncommitted changes and forgot to back them up.  Again, CVS
    would have preserved these changes, because it would have done
    a merge.

Conclusion: remote-mounting sandboxes is dubious, but possible
with much care, and with willingness to absorb the overhead of
cleaning up the inevitable mistakes ... but your stated reason
for remote-mounting them in the first place is even more
dangerous in and of itself.


> (----------------------- caer baedwin ---------------------------)

Wuzzat?

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)