Code Management With CVS Or Submission With Subversion. Gary Kedziora ANL August 19, 2005

Transcription

1 Code Management With CVS Or Submission With Subversion. Gary Kedziora ANL August 19, 2005

2 CVS Branches And Tagging merge-trunk-to-branchid-m merged-from-branchid-to-trunk-n root-branchid point-pointid HEAD Branch-BRANCHID merged-from-trunk-to-branchid-m point-branchid-pointid merge-branchid-to-trunk-n

3 Tagging Conventions BRANCHID = the branch's identifier POINTID = a checkpoint's identifier These should be any of: - "Major_Minor_Patchlevel" - "descriptive_name" - "yyyy_mm_dd" In addition, POINTID's can be: - "descriptive_name_pre-<n>" -- before shaky checkins - "descriptive_name-<n>" -- after shaky checkins N = a merge id: - an integer serial number, starting from 1.

4 Create Branch # Make sure your working copy (of the trunk) is up-to-date: cvs update -d #.. resolve any conflicts at this point, and checkin: cvs comitt # Tag the state on the trunk just before creating the branch: # (WARNING: Do not forget this step! It's nigh impossible # to reliably fix post-facto in a busy repository.) cvs tag root-$branchid # Create the branch (also with "cvs tag", but with a "-b" option): cvs tag -b branch-$branchid # Inspect the existing tags on a sample file: cvs log

5 CVS Branches And Tagging merge-trunk-to-branchid-m merged-from-branchid-to-trunk-n root-branchid point-pointid HEAD branch-branchid merged-from-trunk-to-branchid-m point-branchid-pointid merge-branchid-to-trunk-n Based on CVS Branching HOWTO, Michael Sternberg

6 CVS Branches And Tagging merge-trunk-to-branchid-m merged-from-branchid-to-trunk-n root-branchid point-pointid HEAD branch-branchid merged-from-trunk-to-branchid-m point-branchid-pointid merge-branchid-to-trunk-n

7 Merge Trunk to Branch # Tag the current stage of the trunk as merge point for the branch: cvs tag -r HEAD merge-trunk-$branchid-m # Pull in the trunk changes, i.e., the actual "join": cvs -q up -j root-$branchid -j merge-trunk-to-$branchid-m # NB: If this had been done before, use the previous merge tag as reference: cvs -q up -j merge-trunk-branchid-<m-1> -j merge-trunk-$branchid-m # This creates a diff comprising the changes in the trunk since the branch was # created (root-$branchid) and the intended merge point just tagged # (merge-trunk-to-$branchid-m). # Resolve any conflicts, but not much more, and check in: cvs ci -m "merged from tag merge-trunk-to-$branchid-m" # Immediately tag this stage: cvs tag merged-from-trunk-to-$branchid-m

8 CVS Branches And Tagging merge-trunk-to-branchid-m merged-from-branchid-to-trunk-n root-branchid point-pointid HEAD branch-branchid merged-from-trunk-to-branchid-m point-branchid-pointid merge-branchid-to-trunk-n

9 Merge From Branch To Trunk # Tag the current stage of the branch as merge point intended for the trunk: cvs tag merge-$branchid-to-trunk-n # Switch to the trunk when you have a separate working copy: cd../trunk # Or switch to the trunk -- in-place: cvs update -d -A # Inspect what happened on the trunk SINCE branching. # - This is where the important "root-$branchid" tag comes in handy. cvs diff -r root-$branchid # Changes in branch w.r.t. trunk (your work, to be merged): cvs diff -r HEAD -r branch-$branchid # Total changes in branch since its root (should look familiar): cvs -q diff -r root-$branchid -r branch-$branchid

10 Merge From Branch To Trunk # Merge in the changes from the branch: cvs update -d -j branch-$branchid # If a branch had been merged before, there will be this error: # # "cvs server: file foo exists, but has been added in # revision bar" # # In this case, the diffs to be merged must be taken w.r.t. # the PREVIOUS merge (note: n-1"), as follows: cvs up -d -j branch-$branchid-merge-to-trunk-<n-1> -j branch-$branchid # check status, look for conflicts ("C"): cvs -nq up # Resolve conflicts and test.

11 Merge From Branch To Trunk # Check in the changes: # Put the merge tag assigned above in the log message. # Feel free to add a summary of all the changes in the # branch or since the last merge. # # BTW: At this point, it doesn't matter whether changes came # from a merge and/or any other editing. # cvs ci -m "merged-$branchid-trunk-n... summary blah blah" # If you're curious, inspect the logs: cvs log # Tag the trunk: cvs tag merged-from-$branchid-to-trunk-n

12 CVS Branches And Tagging merge-trunk-to-branchid-m merged-from-branchid-to-trunk-n root-branchid point-pointid HEAD branch-branchid merged-from-trunk-to-branchid-m point-branchid-pointid merge-branchid-to-trunk-n

13 Subversion Most current CVS features. Subversion is meant to be a better CVS, so it has most of CVS's features. Directories, renames, and file meta-data are versioned. It allows arbitrary metadata ("properties") to be versioned along with any file or directory, and provides a mechanism for versioning the `execute' permission flag on files. Commits are truly atomic. No part of a commit takes effect until the entire commit has succeeded. Revision numbers are percommit, not per-file; log messages are attached to the revision, not stored redundantly as in CVS. Client/server protocol sends diffs in both directions. Costs are proportional to change size, not data size.

14 Subversion Versioning of symbolic links. Unix users can place symbolic links under version control. The links are recreated in Unix working copies, but not in win32 working copies. Efficient handling of binary files. Subversion is equally efficient on binary as on text files, because it uses a binary diffing algorithm to transmit and store successive revisions. Parseable output. All output of the subversion command-line client is carefully designed to be both human readable and automatically parseable; scriptability is a high priority. Localized messages. Subversion uses gettext() to display translated error, informational, and help messages, based on current locale settings.

15 Subversion Subversion has the ability to back out changes before going to production using an activity branching model. We can allow developers to branch per activity and only merge to the main source base after code reviews have been performed. If there are problems, we have one revision we can back out that includes the full change set for that change. In CVS we had to go through each file looking for revisions that were effected by a change. Subversion now manages this for us. From customer testimonials.

16 Subversion Open-source projects that use subversion: ASF: The Apache Software Foundation. KDE: The K Desktop Environment. Samba: SMB services for *nix systems. Mono: an open-source implementation of C#/.NET. PuTTY: Win32 SSH/Telnet implementation Zope: web application server/framework. Plone: content management system. Xiph: open-source multimedia protocols. Debian: a popular Linux distribution. CUPS (Common UNIX Printing System): printing services for Unixbased OS's. And more