[Mdarad-toolbox-devs] Re: IMPORTANT: Merging to SVN

[François Eric]

Here is the document I had prepared.  It is about VSS to SVN migration but you'll find important info on command mappings between VSS, CVS and SVN and also some pros and cons on using SVN... Alternatives Although there are many alternatives for an RCS, the three most popular are: ClearCase CVS Subversion Clearcase pros Mature product with good support Very extensive functionality list cons Very expensive Quite complicated Not well suited for small to medium companies. CVS PROS Widely used Almost all applications have plugins for CVS Documentation very extensive Most developers know CVS and know how to use it Tags and branches are simple and intuitive Cons As for VSS, does not allow atomic commits When moving a file from one directory to another, the history is lost for this file. It is not possible to store an empty folder in the repository, only files are taken in account Old application that is very difficult to patch and/or modify. Subversion Subversion is an OpenSource tool that was built based on the CVS architecture but with the plan to fix some of the problems related to the general architecture of CVS. Pros Built on same principle as CVS Allows atomic commits Moving file from one directory to another does not delete history Directories are treated as files and can therefore be kept in repository without any files under them Well built application that is easier to modify. Cons Still young product. Plugins are not yet available for all applications chosen solution Because of the earlier mentioned pros and cons of alternative solutions, Subversion was chosen as the tool to replace VSS. how to migrate from vss to SVN This section will detail how to migrate from VSS to SVN: what developers should know and what “project creators” or Subversion administrators should also know. repository migration preserving history There are some migration scripts that can be found to migrate a VSS repository to a SVN repository. This script (reference document [3]) is an unofficial script developed by a user who needed it done in his own projects. The advantage of using such a script would be to preserve the history of files and folders. On the other hand it is not guaranteed that the script will fill our needs and there might be need to customize the scripts. This can be time consuming and the effort may not be worthwhile. My suggestion is to recreate the repositories in Subversion and to keep the VSS repositories and clients active for a determined period of time so that the history can still be consulted during the transition (only in read only). Once this period is over, we can archive the VSS repositories and move on to only Subversion. storing projects in SVN Contrarily to CVS and VSS, SVN needs a certain knowledge of the repository when creating a project. In CVS you would directly create a module and the repository would automatically create a head branch and manage your branches and tags automatically. In SVN it is not the case, the tags and branches are considered to be simple “copies” of the main development line (called “trunk” in Subversion). Therefore, it is important when creating a new module to use this directory tree convention to store the project: <project name> trunk tags branches The files are stored under trunk (main line of development). When creating a tag, it is important to specify the tags directory and to append the name of the revision: http://<url_for_repository>/<project_name>/tags/<tag_name> The same concept applies for branches. The difference between branches and tags is that tags are lightweight copies (only the differences are copied) whereas the branches are total copies of the “trunk” or selected tag or branch. Here is an example of the VMIS-Client tree structure: vmis-client Trunk Src Com … Scripts … Tags Branches If we want to create a tag v1.0, we will create it in the following directory: http://<url_for_repository>/vmis-client/tags/v1.0 The resulting repository, will look like so: vmis-client Trunk Src Com … Scripts … Tags Src Com … Scripts … Branches It is not so complicated but it takes getting used to and asks for a little more discipline (or knowledge) of the repository to developers and especially those who will have to create the project since they will have to create the “base directory tree” for every project they check in. developer specificiations Mapping between vss and SVN commands There is a world of difference between VSS and SVN commands but not much difference between the CVS and SVN commands. If the developer is confortable with CVS, there will not be much to learn but coming from VSS it is a little more complicated VSS Command CVS Command SVN Command Difference GetLatestVersion Update Update The SVN and CVS update will notify if files are pruned from repository so you can remove them from local repository (VSS would not). Add Add Add Even though they have the same name, there are very big differences. The VSS adds the file directly to the repository whereas in CVS and SVN it is a local note that is made. The file is only added during the commit. Delete Delete Delete Same as add but for delete Checkin Commit Commit These commands pretty much do the same but SVN has atomic commits (explained earlier). Checkout Edit -- There is no edit in SVN, but there is a lock command to lock a file before using it. Undo Checkout Unedit Revert (and unlock if necessary) ShowDifferences Update –n Status Label Tag Copy A tag in SVN is an actual copy. Therefore it must be copied in the tags section (see previous explanation). (manual copy) Branch Copy In VSS dragging and dropping a branch was the equivalent of a “branch”. The major difference between the 2 is the commit. In CVS and SVN, you can add files, delete files, and modify files without every modifying the repository. Only when the commit is made are the changes sent to the repository. This is a HUGE advantage since you can make sure that the repository is always in a clean state. There are other commands and differences but this should give a quick overview and help as a reference for developers to migrate from one platform to the other. how to plug clients on projects repositories As explained in section 7.1.2, the main development line (also known as HEAD or trunk) is stored in the “trunk” directory. Therefore when trying to connect a client to the project, it is important to connect to the trunk directory and not the “root” of the project directory. Otherwise every time a tag or a branch is committed, you will be synchronized with this on your local client and this can become very heavy (disk wise). You can always switch to a tag version if you need to modify a specific tag but usually you will create a branch from a tag and modify the branch directly. François Eric wrote: Hi, Since there have been regular problems with CVS, I will be migrating mdarad-toolbox to subversion (SVN).  Therefore, in a few days (time for tests), you will not be able to checkout mdarad through CVS. If you use Eclipse, a good plugin for SVN is: http://subclipse.tigris.org/ Otherwise you can use an independent client like Tortoise SVN (which is like tortoise cvs): http://tortoisesvn.tigris.org/ Here are documents explaining the differences between CVS and SVN: - http://better-scm.berlios.de/comparison/comparison.html I had also prepared a document to explain the main differences between cvs and svn.  I will forward it as soon as I can get my hands on it. This means that NO CHECKIN should be done in CVS since these changes will not be updated in the SVN version.  I will be merging the cruisecontrol process to use svn. BTW: To checkout the projects, you need to point to the trunk (equivalent of HEAD in cvs). So here are the four urls to mdarad-toolbox: https://svn.sourceforge.net/svnroot/mdarad-toolbox/trunk/mdarad-genapp https://svn.sourceforge.net/svnroot/mdarad-toolbox/trunk/mdarad-framework https://svn.sourceforge.net/svnroot/mdarad-toolbox/trunk/cruisecontrol https://svn.sourceforge.net/svnroot/mdarad-toolbox/trunk/cartridges If you have any questions regarding the use of subversion, please let me know, François ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Mdarad-toolbox-devs mailing list Mdarad-toolbox-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mdarad-toolbox-devs