[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS Update Behaviour
From: |
Arcin Bozkurt - Archie |
Subject: |
Re: CVS Update Behaviour |
Date: |
22 Feb 2002 11:09:21 -0500 |
On Thu, 2002-02-21 at 21:03, Paul Sander wrote:
> >--- Forwarded mail from address@hidden
>
> >[ On , February 21, 2002 at 18:55:21 (-0500), Arcin Bozkurt - Archie wrote: ]
> >> Subject: Re: CVS Update Behaviour
> >>
> >> On Thu, 2002-02-21 at 17:45, Greg A. Woods wrote:
> >> >
> >> > Don't get stuck on this idea of trying to keep track of everything back
> >> > to the beginning of time with one RCS file.
> >>
> >> So, you don't believe that history of those files are that important.
>
> >Of course it's important -- it's your record of what happened to that
> >code through its lifetime. It can tell you how bugs were fixed in the
> >past, and how new bugs were introduced, and all kinds of management
> >level information such as how many lines of code changed, who changed
> >them, etc., etc., etc.
>
> >It just doesn't have to be all in the same RCS file. The idea that it
> >should is a very dangerous fallacy, esp. w.r.t. to CVS.
>
> That last paragraph is utter crap. Without having the entire history
> of a file's lifetime in one container, it's much much harder to track
> changes that are made before the last reorg. And it's especially difficult
> to track migrations through the reorg with respect to branches. For
> example, it's much harder to migrate bug fixes from old releases to new
> development if the new stuff involves renaming files.
In the problem I am facing, we are not, at the moment, thinking of
assigning new purposes to existing files and we are not planning any
renamings...
>
> And going the other way, suppose a rename was done and a new file takes
> the place of the old one in the filesystem. Now you have a dangerous
> situation in which a single RCS files contains partial version histories
> of multiple files. It's dangerous because it opens up the possibility of
> someone merging inappropriate changes from one branch to another, from
> one file to another.
>
A question on merge behaviour of cvs: Will CVS be able to follow a file
disappearing in one module, appearing in another one? I would say no.
And therefore a merge would not be able to propogate bugfixes on that
file even though the file is not deleted, and resurrected for another,
etc.
Am I right?
> Here is an illustration:
>
[... : illustration understood and taken out for clarity ]
>
> The fact that CVS doesn't map RCS files uniquely to sources in the
> context of reorganizations doesn't make the requirement to do so
> a fallacy. It makes CVS broken.
>
> >--- End of forwarded message from address@hidden
>
- Re: renaming under CVS, (continued)
- Re: renaming under CVS, Paul Sander, 2002/02/27
- Re: renaming under CVS, Greg A. Woods, 2002/02/27
- Re: CVS Update Behaviour, Nagy Gabor, 2002/02/25
- Re: CVS Update Behaviour, Greg A. Woods, 2002/02/26
- Re: CVS Update Behaviour, Nagy Gabor, 2002/02/26
- Re: CVS Update Behaviour, Noel Yap, 2002/02/26
- Message not available
- Re: CVS Update Behaviour, Kaz Kylheku, 2002/02/25
- Re: CVS Update Behaviour,
Arcin Bozkurt - Archie <=
- Re: CVS Update Behaviour, Paul Sander, 2002/02/22
- Re: CVS Update Behaviour, Greg A. Woods, 2002/02/22
- Re: CVS Update Behaviour, Noel Yap, 2002/02/22
- Re: CVS Update Behaviour, Greg A. Woods, 2002/02/22
- Re: refactoring under CVS, Noel Yap, 2002/02/23
Re: CVS Update Behaviour, Colm Murphy, 2002/02/25
Re: CVS Update Behaviour, Kaz Kylheku, 2002/02/25