Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Research on how Higgins could convert from CVS to SVN

I'm in the process of setting up a local Subversion repository so that I can attempt a trial run of the CVS conversion script against the Higgins repository.  I'll report the results on tomorrow's conference call.  In the mean time, for those of you who aren't familiar with Subversion, I found the following section from "Version Control with Subversion" very informative:


When discussing the features that Subversion brings to the version control table, it is often helpful to speak of them in terms of how they improve upon CVS's design.  Subversion provides:


Directory versioning


CVS only tracks the history of individual files, but Subversion implements a “virtual” versioned filesystem that tracks changes to whole directory trees over time. Files and directories are versioned.


True version history


Since CVS is limited to file versioning, operations such as copies and renames—which might happen to files, but which are really changes to the contents of some containing directory—aren't supported in CVS. Additionally, in CVS you cannot replace a versioned file with some new thing of the same name without the new item inheriting the history of the old—perhaps completely unrelated—file. With Subversion, you can add, delete, copy, and rename both files and directories. And every newly added file begins with a fresh, clean history all its own.


Atomic commits


A collection of modifications either goes into the repository completely, or not at all. This allows developers to construct and commit changes as logical chunks, and prevents problems that can occur when only a portion of a set of changes is successfully sent to the repository.


Versioned metadata


Each file and directory has a set of properties—keys and their values—associated with it. You can create and store any arbitrary key/value pairs you wish. Properties are versioned over time, just like file contents.


Choice of network layers


Subversion has an abstracted notion of repository access, making it easy for people to implement new network mechanisms. Subversion can plug into the Apache HTTP Server as an extension module. This gives Subversion a big advantage in stability and interoperability, and instant access to existing features provided by that server—authentication, authorization, wire compression, and so on. A more lightweight, standalone Subversion server process is also available. This server speaks a custom protocol which can be easily tunneled over SSH.


Consistent data handling


Subversion expresses file differences using a binary differencing algorithm, which works identically on both text (human-readable) and binary (human-unreadable) files. Both types of files are stored equally compressed in the repository, and differences are transmitted in both directions across the network.


Efficient branching and tagging


The cost of branching and tagging need not be proportional to the project size. Subversion creates branches and tags by simply copying the project, using a mechanism similar to a hard-link. Thus these operations take only a very small, constant amount of time.


Hackability


Subversion has no historical baggage; it is implemented as a collection of shared C libraries with well-defined APIs. This makes Subversion extremely maintainable and usable by other applications and languages.

>>> "Mary Ruddy" <mary@xxxxxxxxxxxxxxxxx> 11/09/07 9:20 AM >>>

When the Higgins project was started, Eclipse only offered CVS, not SVN. So even though SVN has advantages, we had to use CVS.  SVN is now available to projects on request.


 

SVN has some features that will give us more control over the build process.

 

F

or example: Andy "used to use CVS on another project and 

moved to SVN.  Originally his project was hesitant, but they found that it made doing nightly builds much easier as a nightly build can be kicked off on a particular revision. Didn't need to worry about tagging, while letting developers check in ahead of the builds.  Also can get atomic commits (all or nothing).. Also able to use SVN revision in the file name of a resulting build so that if someone subsequently reported a bug, we could go back to the exact source for the build".


 


On the Higgins developers call yesterday, we discussed the pros and cons.  Dev notes to follow. We had a guest speaker on the dev call from the Financial Services Technology Consortium and we agreed to let him review the notes on his presentation to ensure accuracy, so the notes are delayed. 

 


During the call

Andy was nominated to research preparations for doing a dry run of the conversation as part of formally preparing for any actual conversion.  More to follow.


 

Below is the overview information I got on the process from Matt Ward, one of the Eclipse web masters: 


 

 

Basically a project needs to decide on it's developers list, and then the PL sends in a request to have the repository moved from cvs to svn.

We use the cvs2svn tool, but there are a couple of caveats from the

documentation:

1) CVS doesn't record complete information about your project's history.

For example, CVS doesn't record what file modifications took place within the same CVS commit. Therefore, cvs2svn attempts to infer from CVS's incomplete information what /really/ happened in the history of your repository. So the second goal of cvs2svn is to reconstruct as much of your CVS repository's history as possible.

2)One of the most important topics to consider when converting a repository is the distinction between binary and text files. If you accidentally treat a binary file as text *your repository contents will be corrupted*.

For more details check out http://cvs2svn.tigris.org/cvs2svn.html

-Matt.


Back to the top