Edgewall Software

Changes between Version 40 and Version 41 of TracTicketsCustomTimeFields


Ignore:
Timestamp:
Jan 16, 2012, 2:00:56 AM (12 years ago)
Author:
Steffen Hoffmann
Comment:

push latest new - still most of the page is very outdated

Legend:

Unmodified
Added
Removed
Modified

  • TracTicketsCustomTimeFields

    v40 v41  
    44
    55== Code review ==
    6 Proposed code changes for Trac trunk reside in a Mercurial repository at bitbucket.org ^note 1^. The Mercurial Queue (MQ) aside that repo is the patch stack itself with some meta-data ^note 2^:
    7 
    8  http://bitbucket.org/hasienda/custom-time/
    9 
    10 The repo will be more or less behind current SVN HEAD most of the time, while the MQ linked above is updated quite often to reflect the development of custom time field support ^note 3^.
     6Proposed code changes for Trac `trunk` reside in a Mercurial repository at bitbucket.org ^note 1^. This repository isn't a repository clone, but a patch queue to Trac's SVN repository mirror to Mercurial instead:
     7
     8 https://bitbucket.org/hasienda/trac-1942
     9
     10Mercurial Queue (MQ) is a powerful tool to bring dynamic, mutable changesets to otherwise immutable changesets of this distributed version control system (DVCS). But anyone can use it as a patch stack with some meta-data. Just see the series file for the patch order and optionally more related information ^note 2^.
     11
     12The repo will not always apply cleanly to current Mercurial tip/SVN HEAD. But re-basing is easy with MQ, and this has potential to drive even rapid development towards custom time field support ^note 3^.
    1113
    1214You're invited to pull right now, but save a backup of your db before testing, please. I never broke the db of my development system. However, there might still lure some serious bugs, that I'm currently not aware of but could hit you, so you may need your backup to recover from a bad db. You've been warned. See [#KnownBugs Known Bugs] for more details.
    … …  
    1618 * edits to (the discussion section of) this wiki page
    1719 * comments to #1942
    18  * work on a publicly reachable clone of my Mercurial Queue
     20 * work on a publicly reachable clone of the Mercurial Queue
    1921 * private e-mail
    20  * push to my Mercurial Queue after initial per-developer arrangement inside bitbucket.org
     22 * push to the Mercurial Queue after initial per-arrangement inside bitbucket.org (current Trac core developers enabled in advance)
    2123
    2224I urge you to report back on any failure from code review or your testing. For test results, as always, mention your local setup (Trac version/revision, if not taken from my repo, Mercurial revision id of the patches). Any feedback will help to make the patches ready for production and later bring the code into Trac itself. That was my goal right from the start, not to produce just another [http://trac-hacks.org Trac hack].
    2325
    2426=== Notes ===
    25 1. My repository is a clone of rblank's Mercurial repository, that in turn consists of changesets imported from Trac SVN repo.
    26 2. The common setup for Mercurial Queue puts the patches into a Mercurial repo on their own. So looking at [http://bitbucket.org/hasienda/custom-time/changesets the changes] during development is easy.
    27 3. Since there is no other sane way to push the changes to a public repository without making them irreversible, I'll not dare to push real revisions before substantial clearing with core Trac developers. Some of the patches will get forwarded independently for early, stepwise adoption into Trac, like that published in #9209).
     271. The common setup for Mercurial Queue puts the patches aside the main repository - into a Mercurial repo on it's own. So looking at [https://bitbucket.org/hasienda/trac-1942/changesets the changes] during development is as easy as looking at development in any repository.
     282. Since there is no other sane way to push changes to a public repository without making them irreversible, this look like the ideal compromise until substantial clearing with core Trac developers has been reached. However, some code already got forwarded for adoption into Trac `trunk`, like the one published in #9209).
    2829
    2930== !HowTo testing ==
    30 For help on applying the patches to Trac trunk source the traditional way, i.e. with {{{patch}}}, look at the patch documentation in the [http://bitbucket.org/hasienda/custom-time/src/tip/series series] file.
     31''Note: This is very outdated now. Until I step-up with a full revision you can still try and checkout the patch files and apply them on-top of trac `trunk` r10883.''
     32
     33For help on applying the patches to Trac trunk source the traditional way, i.e. with {{{patch}}}, look at the patch documentation in the [https://bitbucket.org/hasienda/trac-1942/src/tip/series series] file.
    3134
    3235But you'll see, Mercurial will save you and me some time and hassle, even more for true collaboration on bugs and feature requests. For the lazy or impatient ones not familiar with Mercurial I recommend to go along the lines of the following walk-through (Debian way).
    … …  
    4245$> mkdir ~/trac0.12-dev_custom-time
    4346$> cd ~/trac0.12-dev_custom-time
    44 $> hg qclone https://hasienda@bitbucket.org/hasienda/custom-time
     47$> hg qclone https://hasienda@bitbucket.org/hasienda/trac-1942
    4548$> cd ./custom-time
    4649$> hg qseries
    … …  
    5659$> python ./setup.py build
    5760$> sudo python ./setup.py install --prefix=/usr/local
    58 $> env LANG=de_DE.UTF-8 /usr/local/bin/tracd -d -s --port 8000 /trac-environments/sandbox
     61$> /usr/local/bin/tracd -d -s --port 8000 /trac-environments/sandbox
    5962}}}
    6063