Changes between Version 7 and Version 8 of SvnRules


Ignore:
Timestamp:
Mar 30, 2017, 1:03:56 PM (2 years ago)
Author:
dneise
Comment:

quicker branching

Legend:

Unmodified
Added
Removed
Modified
  • SvnRules

    v7 v8  
    3636Is suppose you are creating a branch of the most recetn version of the trunk (of course it is also possible to create branches of historic versions, we'll come to that later)
    3737
    38 Technically your branch could sit anywhere in the svn repository, but we agreed on having them in one central place for simplicity.
     38(Inspired by http://guides.beanstalkapp.com/version-control/svn-branching.html)
    3939
    40     {{{
    41     svn copy https://trac.fact-project.org/svn/trunk/Mars https://trac.fact-project.org/svn/branches/MyAwesomeNewMarsBranch -m "Just having an awesome idea..."
    42     }}}
    43    
    44 Now just checkout your new branch as you would checkout the trunk version of mars.
     40Let's say you want to add some new feature to a FACT++ program. I assume you have the trunk checked out on you laptop somewhere (say `~/fact/FACT++`).
     41You might want to make sure, you really branch off the most recent version:
    4542
    46     {{{
    47     svn co https://trac.fact-project.org/svn/branches/MyAwesomeNewMarsBranch mars_mybranch
    48     }}}
     43{{{
     44~/fact/FACT++:$ svn update
     45Updating '.':
    4946
    50 Actually if you checked out the trunk version into a folder called `mars` and your private branch into a folder called `mars_mybranch`, you might want to rename `mars`now to `mars_trunk` and create a symlink called `mars` that points to the version you are currently working with most.
     47At revision 18794.
     48}}}
    5149
    52 In case you set `LD_LIBRARY_PATH` or `PATH` to the `mars` folder, changing versions is nothing more than overwriting that symlink.
     50Create a remote branch (without checking it out -> very fast)
    5351
    54     {{{
    55     ln -s mars_trunk mars
    56     rm mars
    57     ln -s mars_mybranch mars
    58     }}}
     52{{{
     53~/fact/FACT++:$ svn copy ^/trunk/FACT++ ^/branches/FACT++_ticket-15 -m "Branch for ticket-15"
     54Committing transaction...
     55Committed revision 18795.
     56}}}
     57
     58Copy you working dir locally into a new branch (also fast -> no network load):
     59{{{
     60~/fact/FACT++:$ cp -r . ../FACT++_ticket-15
     61}}}
     62
     63Now comes the trick:
     64{{{
     65~/fact/FACT++:$ svn switch ^/branches/FACT++_ticket-15 ../FACT++_ticket-15 --ignore-externals
     66At revision 18795.
     67}}}
    5968
    6069Feel free to work in your branch the way you like best, but if you later want to merge your branch back into the trunk, it might be useful to rather do many smaller commits than one big commit.
    61 
    62 === Creating a Branch from a historic version ===
    63 
    64 It is actually common practice that not the most recent version of the trunk is used for production. Very often software developers create certain release versions of their code, which is used for production, while development continues in the trunk. Code releases are often marked by so called **tags** for easy reference, but so far FACT did not follow this practise.
    65 However you might find yourself in the situation, that you want to base your development on a version, from a given date.
    66 
    67 So suppose you want to let your branch be based on Mars, as it was on e.g. 26.05.2014, you can use the trac timeline to find the according revision number. https://trac.fact-project.org/timeline
    68 
    69 In our example we learn, that the last change on that day was done in revision 17899, so we can type:
    70 
    71     {{{
    72     svn copy -r17899 https://trac.fact-project.org/svn/trunk/Mars https://trac.fact-project.org/svn/branches/MarsBranchBasedOn17899 -m "another idea, ..."
    73     }}}
    74 
    75 After checking out this branch, you can check if you in fact did the right thing by changing into the working directory of your branch and do:
    76 
    77     {{{
    78     svn co <your branch>
    79     cd <into that folder>
    80     svn log -v -r0:HEAD --stop-on-copy --limit 1
    81     }}}
    82 
    83 You'll get something like:
    84 
    85     {{{
    86     rxxx | Author | <A DATE> | 1 line
    87     Changed paths:
    88         A /project/branches/branch (from /project/trunk/folder:ryyy)
    89     }}}
    90    
    91     The revision and path your branch were base on are: /project/trunk/folder:ryyy.
    92    
    93 == Before you commit something ==
    94 
    95 Although the svn is a versioning system which keeps the history, it should be kept clean as much as possible. We are all humans, so we make mistakes, but svn should help us to cure real mistakes as fast as possible, not be sloppy and create more mistakes.
    96 
    97 Here are a few simple rules which help a lot to make sure you know what you do when accessing the svn and which help you to properly document your changes. The later is important if a problems needs to be tracked. Not only the comments to the code of question might be important, but also other comments. To find the commit in question as soon as possible, comments which tells you the kind of the commit are very important (cosmetics, only includes, major code change, etc) and the meaning (fixed a compiler warning, fixed a memory leak, ...)
    9870
    9971== Comitting ==