[avr-libc-dev] Re: Current branches

[Ivan Shmakov]

>>>>> Joerg Wunsch <address@hidden> writes:

 >> The question is about HEAD and 1.6.  Today there is no projects to
 >> force its different.

 > Well, it won't last for too long, usually...

 >> May be any method to reduce manual work before HEAD and 1.6 are
 >> equivalent?

 > Unfortunately, I don't know of any.  Usually, whenever I've got
 > something around on the HEAD that is also candidate for the stable
 > branch, I run a "cvs diff -u", save the output in a file, and then
 > patch that into the stable branch afterwards (using "patch -p0").
 > When running the cvs diff before committing, there are no changes to
 > $Id$ yet.

        Well, this problem is addressed by the modern version control
        systems, particularly of the distributed VCS breed, such as Git
        [1], Bazaar [2], Mercurial [3] and the like.

        As an illustration to the above, I'd like to provide a simple
        example, using the Bazaar version control system.  I believe
        that the general workflow will be quite familiar to the users of
        other VCSes (including non-distributed ones such as CVS.)

        The example is as follows:

        * initialize a repository for a HEAD:

    $ bzr init /where/is/foo-head-repo
    $ 

        * checkout a working copy, `cd' to it:

    $ bzr co   /where/is/foo-head-repo/ foo/ 
    $ cd foo/ 
foo $ 

        * put some random contents to the working copy and commit the
          additions:

foo $ cal | tee calendar.text 
   December 2007    
Su Mo Tu We Th Fr Sa
                   1
 2  3  4  5  6  7  8
 9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31               
foo $ bzr add calendar.text 
added calendar.text
foo $ bzr commit -m 'calendar.text: New file.' calendar.text 
Committing revision 1 to "/where/is/foo-head-repo/".
added calendar.text
Committed revision 1.
foo $ 

        * since the whole reason for this example is to show the merging
          of the branches, we now create a branch and checking a working
          copy out of it:

foo $ cd .. 
    $ bzr branch /where/is/foo-head-repo /where/is/foo-1.0-repo 
Branched 1 revision(s).
    $ bzr co /where/is/foo-1.0-repo/ foo-1.0/ 
    $ cd foo-1.0/ 
foo-1.0 $ 

        * change the contents and commit the changes, so that we'll have
          one more revision:

foo-1.0 $ cal 1 2008 >> calendar.text 
foo-1.0 $ bzr diff 
=== modified file 'calendar.text'
--- calendar.text       2007-12-25 14:57:24 +0000
+++ calendar.text       2007-12-25 15:08:16 +0000
@@ -6,3 +6,11 @@
 16 17 18 19 20 21 22
 23 24 25 26 27 28 29
 30 31               
+    January 2008    
+Su Mo Tu We Th Fr Sa
+       1  2  3  4  5
+ 6  7  8  9 10 11 12
+13 14 15 16 17 18 19
+20 21 22 23 24 25 26
+27 28 29 30 31      
+                    

foo-1.0 $ bzr commit -m 'calendar.text (January 2008): Added a month.' \
              calendar.text 
Committing revision 2 to "/where/is/foo-1.0-repo/".
modified calendar.text
Committed revision 2.
foo-1.0 $ 

        * by now, we have two branches (and two respective working
          copies):

foo-1.0 $ bzr log 
------------------------------------------------------------
revno: 2
committer: J. Random Hacker <address@hidden>
branch nick: foo-1.0
timestamp: Tue 2007-12-25 21:09:35 +0600
message:
  calendar.text (January 2008): Added a month.
------------------------------------------------------------
revno: 1
committer: J. Random Hacker <address@hidden>
branch nick: foo
timestamp: Tue 2007-12-25 20:57:24 +0600
message:
  calendar.text: New file.
foo-1.0 $ 

foo $ bzr log 
------------------------------------------------------------
revno: 1
committer: J. Random Hacker <address@hidden>
branch nick: foo
timestamp: Tue 2007-12-25 20:57:24 +0600
message:
  calendar.text: New file.
foo $ 

        * then, we merge the 1.0 changes into the HEAD (though we'd
          usually do it the other way), checking that the diff is sane,
          and commit the changes:

foo $ bzr merge /tmp/foo-1.0-rep/
 M  calendar.text
All changes applied successfully.
foo $ bzr diff 
=== modified file 'calendar.text'
--- calendar.text       2007-12-25 14:57:24 +0000
+++ calendar.text       2007-12-25 15:12:30 +0000
@@ -6,3 +6,11 @@
 16 17 18 19 20 21 22
 23 24 25 26 27 28 29
 30 31               
+    January 2008    
+Su Mo Tu We Th Fr Sa
+       1  2  3  4  5
+ 6  7  8  9 10 11 12
+13 14 15 16 17 18 19
+20 21 22 23 24 25 26
+27 28 29 30 31      
+                    

foo $ bzr commit -m 'Imported changes from the 1.0 branch.'
Committing revision 2 to "/where/is/foo-head-repo/".
modified calendar.text
Committed revision 2.
foo $ 

        * now, we can check that the changes were actually committed;
          note that we won't be specifying the log message once more:

foo $ bzr log 
------------------------------------------------------------
revno: 2
committer: J. Random Hacker <address@hidden>
branch nick: foo
timestamp: Tue 2007-12-25 21:15:23 +0600
message:
  Imported changes from the 1.0 branch.
    ------------------------------------------------------------
    revno: 1.1.1
    committer: J. Random Hacker <address@hidden>
    branch nick: foo-1.0
    timestamp: Tue 2007-12-25 21:09:35 +0600
    message:
      calendar.text (January 2008): Added a month.
------------------------------------------------------------
revno: 1
committer: J. Random Hacker <address@hidden>
branch nick: foo
timestamp: Tue 2007-12-25 20:57:24 +0600
message:
  calendar.text: New file.
foo $ 

        NB: it's usual for DVCS to track the list of changes already
        merged for you, so you won't merge the same thing twice
        accidentally, e. g.:

foo $ bzr merge /tmp/foo-1.0-rep/
Nothing to do.
foo $ 

        In the example above, we've used different directories on the
        local filesystem to hold the different branches.  However, the
        DVCS approach is not limited to it -- you may make your own
        branches out of an HTTP-accessible remote repository:

$ bzr branch http://where/is/foo-head-repo/ /where/is/foo-my-repo/

        and merge in the changes stored in remote repositories as well:

foo-my $ bzr merge http://where/is/foo-head-repo/ 

        By offering the ability of inter-repository branching and
        merging, DVCS can offer the benefits of VCS to every interested
        person, and not just to the ones holding the keys from the
        repository.

        With tools like git-svn(1) (included into Git) and Tailor [4],
        it's possible to ``convert'' the entire CVS history of the
        project into a DVCS repository.

        (Indeed, it's what I did with the `avr-libc' repository and I
        hope that it didn't put too much load onto the server; the
        resulting Git repository is available via HTTP [5], though I'd
        generally not recommend making branches out of it.)

[...]

[1] http://git.or.cz/
[2] http://bazaar-vcs.org/
[3] http://www.selenic.com/mercurial/
[4] http://progetti.arstecnica.it/tailor
[5] http://theory.asu.ru/~ivan/download/git-ivcs/avr-libc.tailor.git/