Re: renaming under CVS

[Noel Yap]

--- "Greg A. Woods" <address@hidden> wrote:
> [ On Sunday, February 24, 2002 at 20:59:30 (-0800),
> Noel Yap wrote: ]
> > Subject: Re: renaming under CVS
> >
> > Let me explain so even you can understand: 
> Developer
> > A should be able to modify a file while developer
> B
> > renames it.  The merge should go gracefully and
> > seemlessly regardless of who checked in first
> since
> > there is no conflict.  But this isn't true when
> using
> > CVS.
> 
> In the original scenario both developers were
> working on different
> branches.
> 
> Developer-A can easily modify all the files on
> branch-A without any
> interference whatsoever while developer-B renames a
> file on branch-B.
> Since you won't be merging between branch-A and
> branch-B without first
> renaming the same file on branch branch-A there's no
> conflict.

And how transparent (aside from some output) is all
this to branch A?

> In the new scenario you apparently propose above,
> which seems to have
> been the one stuck hidden inside your mind all
> along, yes, some
> co-ordination is necessary between all developers
> working on the same
> branch.  However all that's needed is for all
> developers to be aware of
> the rename, and if they all read the commit messages
> then they'll all be
> aware of the rename now won't they.

You completely miss the point.  This is like saying
that we can completely remove "cvs update".  After
all, CVS does abort the commit when a merge is
necessary.  It would then be up to the user to merge
manually without any assistance from CVS.

> Perhaps you've never done this so you're confused
> about what will happen.

I have done this and learned my lessons.  I now try to
avoid renames when using CVS.  When necessary, I
serialize development among the team to avoid further
complications down the line.

> If you actually try this with a test module and a
> couple of test
> directories, you'll find this isn't actually as big
> a problem as you
> seem to think it is, and it does not require
> serialisation.  You're
> right that the merge doesn't happen seamlessly, but
> that's the nature of
> working with a tool that only tracks changes in the
> contents of files.

And why does it have to be stuck tracking only file
content changes?  Because it's been written in stone
in the design documents?

> I've never had any trouble with renames when
> multiple working
> directories exist for multiple developers, not even
> if every other
> working directory but where the file is renamed
> contains un-committed
> changes to that same file.  It really is quite
> simple to handle, and it
> does not involve committing any changes, or even
> re-applying them
> manually to the new file.

We all know you and your team are not like most
developers.

> You really should test such things out before you
> make false claims.

The only claim I've made was that CVS doesn't handle
renames under concurrent development seemlessly.  You
yourself have confirmed that this is true.

Noel

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com