Warning! This page has the following tags:

• This page is deprecated as of whenever the hosting was changed, but still contains useful information.
• This page needs to be fixed and then moved to the global namespace.

Developer Info

The server and you

Please make sure you've read and understand Rose Hosting's AUP.

In addition, your fellow Agavi developers would like to ask the following of you:

• The server is a VPS, and as such isn't powerful, doesn't have tons of disk space, and is charged for bandwidth in excess of 4G/month. Considering all that:
  • please respect other users' privacy.
  • please refrain from leaving things running when you're not logged in.
  • be concious of bandwidth usage.
  • be concious of disk usage.
• Your shell account user/pass works in trac too. We suggest accessing trac using https. (the ssl cert is self-signed, but it'll do)

Developing

• Never ever do anything without creating a ticket for it. This way, we can easily create CHANGELOGs for releases and keep track of who is working on what.
• Accept tickets once you start working on them.
• Each developer works in their own feature branch where they can work on their changes in isolation until it's ready to be merged into trunk. The branch can be named whatever you want, probably something with your name in it would be useful. :)
  • creating a branch in svn is easy:

    svn cp svn+ssh://svn.agavi.org/home/svn/agavi/trunk svn+ssh://svn.agavi.org/home/svn/agavi/branches/zimba-coolstuff
    

  • First thing you should do when creating a branch is change src/version.php to reflect your new branch, the version# should already reflect the next expected release, change to suit
  • If things change in trunk while you're off working in your branch and you want to integrate those changes into your branch (and you should)

    # First, (if you havent merged anything from trunk in before) find out what rev you started your branch with
    svn log --stop-on-copy
    # It will be the last entry in the output there.. 
    # Now that we have a reference to where our branch left trunk, we can ask svn to give us everything in trunk since the branch
    # from your branch.. let's assume you branched at r3233 and trunk is now 5423
    svn merge -r 3233:5423 svn+ssh://svn.agavi.org/home/svn/agavi/trunk
    
    # check it.. make sure everything is nice and sweet, and commit it to your branch
    # BE SURE TO MAKE A NOTE OF WHAT VERSIONS YOU MERGED (so that you'll have a reference if you need to merge again later on)
    svn ci -m "Synced in changed from trunk: re merged in revs 3233:5423"
    

  • let's say you carry on and now there are MORE changes to trunk you need to sync into your branch..

    # find out what the last rev of trunk you merged in was, if you made comments as suggested above, it'll be the first line of output in the command below.
    svn log --stop-on-copy|egrep -i 'synced|merged'
    
    # Ad with before, now the last time we synced was 5423 and now trunk is at 7867 (man someone's been busy!)
    svn merge -r 5423:7867 svn+ssh://svn.agavi.org/home/svn/agavi/trunk
    
    # check it.. make sure everything is nice and sweet, and commit it to your branch
    # BE SURE TO MAKE A NOTE OF WHAT VERSIONS YOU MERGED (so that you'll have a reference if you need to merge again later on)
    svn ci -m "Synced in changed from trunk: re merged in revs 5423:7867"
    
    

  • When you're ready to merge your changes back into trunk... (see notes below about comitting to trunk first!)
  • If you've kept your branch in sync with changes happening to trunk while you've been working on your branch, you should be able to merge your changes into trunk with something like this..

    svn switch svn+ssh://svn.agavi.org/home/svn/agavi/trunk
    svn up
    At revision 138.
    svn merge svn+ssh://svn.agavi.org/home/svn/agavi/branches/zimba-coolstuff@138 svn+ssh://svn.agavi.org/home/svn/agavi/trunk@138
    

  • if your branch isnt up to date with trunk, you'll need to do it a little differently. Basically, you'll need to merge from the point you branched, or the point you last merged if you're using a branch that you've merged changes from before. Let's say for this example, that was rev 167 and the last changeset made was rev 432. You would merge your changes into trunk with something like:

    svn switch svn+ssh://svn.agavi.org/home/svn/agavi/trunk
    svn up
    At revision 432.
    svn merge -r 167:432 svn+ssh://svn.agavi.org/home/svn/agavi/branches/zimba-coolstuff
    

  • you should reference the revisions you're merging in your log message as it may come in handy for your next merge. (which, if you continued working on this branch would be -r 432:N)
  • you should then review the changes, be extra careful you arent inadvertenly backing out changes because you might be out of sync, or comitting something you forgot about and didnt intend to, etc.

    svn diff
    

  • Either fix your src/version.php (ie: it should match trunk's) or just move it out of the away/delete it, so it doesnt get merged into trunk.
  • make a good log message, use svn diff to review the changeset and describe what the changeset is for, what features it adds, or bugs it fixes. You can also use trac's WikiFormatting in your log message and should reference any tickets your changeset addresses using any of the following keywords:

keyword	what happens
closes	Closes the referenced ticket(s) adding the contents of the commit msg and a link to the changeset to the ticket(s)
fixes	Closes the referenced ticket(s) adding the contents of the commit msg and a link to the changeset to the ticket(s)
references	adds the contents of the commit msg and a link to the changeset to the ticket(s), but does not change the ticket(s)'s status
refs	adds the contents of the commit msg and a link to the changeset to the ticket(s), but does not change the ticket(s)'s status
re	adds the contents of the commit msg and a link to the changeset to the ticket(s), but does not change the ticket(s)'s status
addresses	adds the contents of the commit msg and a link to the changeset to the ticket(s), but does not change the ticket(s)'s status

• You can mix and match the references however you need, for example:

    Removed disfunctional SuperConjobaflabulator, replaced with SimpleConjobaflinkter closes #23, #46, and #54 refs #103.
  

• the above example would result in tickets #23, 46, and 54 being closed plus a link to the change set and the commit message would be appended to those 3 tickets and ticket #103.
• If everything else looks good, commit. Try and make a meaningful log message with your commit describing what the changeset is for, what features are added,

  svn ci 
  

• Feel free (we encourage it!) to discuss your development openly on the forums, -dev mailing list, or in the IRC channel.
• Committing directly to trunk is not prohibited, but please excercise some restraint.
  • A consensus vote to the development list is generally a good idea prior to comitting, giving the other devs a chance to speak up.
  • dependencies (3rd party libraries, etc) should target released versions.
  • Basically, we do our damndest not to break trunk as many of us are using it in production scenerios. More importantly agavi.org runs on a checked out copy of trunk and periodically syncs it up. So if you break it, it'll become pretty obvious pretty fast.
  • So, when it comes to trunk
    1. DONT CHECK IN BROKEDNESS
    2. MAKE SURE EVERYONE IS ON THE UP AND UP WITH YOUR CHANGES BEFORE YOU COMMIT TO TRUNK.
    3. PROFIT