Chris Morgan wrote:> Any reason not to upgrade to subversion? It does a much better job > with handling moved or renamed files although svn doesn't actually > store a 'move' or a 'rename' as a single versioned operation.We discussed moving to another revision control system about a year ago, if I recall correctly. At that time, we decided not to move to another system. I don't recall the exact reasons for not switching, but part of it was that CVS is the "standard" revision control system out there (i.e. everyone already has it on their system). I also recall that, at the time, the cost of switching outweighed the benefits we thought we'd gain. Right now, the moving of files doesn't happen often enough to warrant a change in software (IMHO). I just think that we as a group need to exercise more care when moving files so that we minimize the problems that arise. -- John T.> > Chris > > > On 11/15/05, John Criswell <criswell at cs.uiuc.edu> wrote: > >>Dear All, >> >>For those of you who have write access to the LLVM CVS repository, I >>need to ask you to take more care when moving or renaming files. If >>done improperly, moving files can cause headaches when doing updates >>from the repository or merging revisions between branches (which is >>becoming more common with the vector_llvm branch). >> >>There are two ways that you can move a CVS file: >> >>1) Use the CVS commands: >> >>a) cd into your working directory. Move the file from the old location >>to the new location. >> >>b) Use cvs rm to remove the file from its old location. >> >>c) Use cvs add to add the file to its new location. >> >>d) Use cvs ci to commit the remove and addition of the file. In the >>logs, note the old and new locations of the file. >> >>This approach is simple and it allows files to be added and removed >>properly when using cvs up to update a working directory or merge >>revisions in different branches. It also maintains all of the CVS tags >>on the files correctly. >> >>The problem with this approach is that it does not copy over all of the >>revision history from the old location to the new location. >> >>2) Manipulate the CVS Repository directly: >> >>This method will allow you to copy the revision history of a file into a >>new location. However, you have to perform this operation carefully; >>failure to do it right will make merging to/from branches and cvs >>updates difficult. >> >>Even if you follow these directions, I can't guarantee that cvs up is >>going to work correctly in all cases. But if you're going to copy the >>revision history, following the directions below should help alleviate >>some of the problems. >> >>a) cd into the CVS repository and *copy* the RCS file (the file ending >>with a ,v) from the old location to the new location inside the repository. >> >>Please do NOT remove the old RCS file from the repository. >> >>Please do NOT move it using the mv command. >> >>b) cd into your working copy. Use rm and cvs rm to remove the file from >>its old location. Then use cvs ci to commit the change. Make a note in >>the commit log that you've moved the file, and please indicate its new >>location. >> >>c) Use cvs up in your working directory to get a copy of the file in its >>new location. >> >>d) The file in its new location will have all of the CVS tags that it >>had in its old location (the revision history also contains all of the >>tag information). Use cvs tag -d to remove all of the tags from the new >>file. >> >>Doing this should ensure that the file does not show up in its new >>location when checking out older versions of the source code, nor will >>the file magically appear in a branch that it didn't exist in before. >> >>e) It may also be good to send email to llvmdev detailing what has been >>moved. >> >>My recommendation is to use approach #1 as it is less error prone. >>Approach #2 may still cause problems when merging to/from branches, but >>it should be easier to track where a file has gone if the old version >>has been cvs rm'ed. >> >>Improvements and corrections to the directions above are welcome. Any >>input on how to use Approach #2 and still get cvs up to move files >>correctly when merging to/from branches would be great. >> >>Thanks everybody. >> >>-- John T. >> >>-- >>John T. Criswell >>Research Programmer >>University of Illinois at Urbana-Champaign >>"It's today!" said Piglet. "My favorite day," said Pooh. >> >>_______________________________________________ >>LLVM Developers mailing list >>LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- John T. Criswell Research Programmer University of Illinois at Urbana-Champaign "It's today!" said Piglet. "My favorite day," said Pooh.
John Criswell wrote:> Chris Morgan wrote: > >> Any reason not to upgrade to subversion? It does a much better job >> with handling moved or renamed files although svn doesn't actually >> store a 'move' or a 'rename' as a single versioned operation. > > > We discussed moving to another revision control system about a year ago, > if I recall correctly. At that time, we decided not to move to another > system. I don't recall the exact reasons for not switching, but part of > it was that CVS is the "standard" revision control system out there > (i.e. everyone already has it on their system). I also recall that, at > the time, the cost of switching outweighed the benefits we thought we'd > gain. > > Right now, the moving of files doesn't happen often enough to warrant a > change in software (IMHO). I just think that we as a group need to > exercise more care when moving files so that we minimize the problems > that arise. > > -- John T. >We should probably review this decision at least once a year. If the basis for not moving to svn is that "cvs is the standard", that situation is likely to change. Many organizations are now using svn. It is rapidly becoming "the new standard". At some point it doesn't make sense for us to continue with the "old standard". When that situation occurs is up for debate. I'm just contending we should review this once a year because it is a situation that is in flux. My suggestion is that we target it to coincide with the 2.0 release since that release could have numerous changes that are not backward compatible and moving to svn could be rolled in under that pretext. Reid.
Reid Spencer wrote:> John Criswell wrote: > >> Chris Morgan wrote: >> >>> Any reason not to upgrade to subversion? It does a much better job >>> with handling moved or renamed files although svn doesn't actually >>> store a 'move' or a 'rename' as a single versioned operation. >> >> >> >> We discussed moving to another revision control system about a year >> ago, if I recall correctly. At that time, we decided not to move to >> another system. I don't recall the exact reasons for not switching, >> but part of it was that CVS is the "standard" revision control system >> out there (i.e. everyone already has it on their system). I also >> recall that, at the time, the cost of switching outweighed the >> benefits we thought we'd gain. >> >> Right now, the moving of files doesn't happen often enough to warrant >> a change in software (IMHO). I just think that we as a group need to >> exercise more care when moving files so that we minimize the problems >> that arise. >> >> -- John T. >> > > We should probably review this decision at least once a year. If the > basis for not moving to svn is that "cvs is the standard", that > situation is likely to change. Many organizations are now using svn. It > is rapidly becoming "the new standard". At some point it doesn't make > sense for us to continue with the "old standard". When that situation > occurs is up for debate. I'm just contending we should review this once > a year because it is a situation that is in flux.Agreed. I probably should have mentioned that the decision is not set in stone; staying with CVS is what was decided at the time, but can change in the future.> > My suggestion is that we target it to coincide with the 2.0 release > since that release could have numerous changes that are not backward > compatible and moving to svn could be rolled in under that pretext. > > Reid. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- John T. -- John T. Criswell Research Programmer University of Illinois at Urbana-Champaign "It's today!" said Piglet. "My favorite day," said Pooh.
On Tue, 15 Nov 2005, Reid Spencer wrote:> We should probably review this decision at least once a year. If the basis > for not moving to svn is that "cvs is the standard", that situation is likely > to change. Many organizations are now using svn. It is rapidly becoming "the > new standard". At some point it doesn't make sense for us to continue with > the "old standard". When that situation occurs is up for debate. I'm just > contending we should review this once a year because it is a situation that > is in flux.Basically, at the time, there was not enough of a compelling reason to warrant the change. We don't use branches heavily (which is a source of CVS performance pain) and we don't move files often. Further, I still have hope that distributed source control systems will improve in usability, stability and performance to the point where we can consider using one. In short, switching source control systems because there is something new and sexy out there isn't a compelling thing to do. There should be a real reason to do so, and it should solve real problems for us (outweighing the costs of a change). Finally, we definitely don't want to switch twice.> My suggestion is that we target it to coincide with the 2.0 release > since that release could have numerous changes that are not backward > compatible and moving to svn could be rolled in under that pretext.I don't see that waiting for a 2.0 release is needed if/when we want to change. Further, I'd be perfectly happy if "2.0" was just "1.9" + ".1"... i.e. I don't see a great need for destabilizing or non-backwards-compatible changes to LLVM. -Chris -- http://nondot.org/sabre/ http://llvm.org/