This give some point of view :) Great thanks!

For now I have separate branch for each of my issue. Each branch is
lead from reviewboard master and contain only changes for each issue.
All of issues is merged to "intel" branch. I made some smart command
"intelit" which make greate use from git archive and propagate changes
in intel branch to virtualenv system and of course working reviewboard
copies as well.
I think when I will try use hooks branch or 1.6 I just checkout this
branch and merge all my issues to it. This will be probably easier :)

Thank You for Your time and publishing extra branches :) Today is a
big day - first implementing of ReviewBoard in our team :] So. I have
a grate hope all will go fine, my managers will be charm of this tool
and I get more tasks to help with development :]

On Apr 6, 8:03 am, Christian Hammond <chip...@chipx86.com> wrote:
> The beauty of Git is that you don't have to only base your changes on one
> branch. You can easily merge from multiple branches into your branch.
>
> What I'd recommend is to have a branch, for example "vendor", which is what
> your internal builds will be from.
>
> Then, each feature would go its own feature branch, for the purpose of
> making it easy to port certain things down the road, and maybe to even
> provide patches.
>
> "vendor" would merge from each branch when you're ready to do a new build.
> This is done by:
>
>     $ git checkout vendor
>     $ git merge my-feature
>
> You may have to resolve some merge conflicts, but then you'd have that
> feature in your branch. Periodically, you'd also merge from "master". If you
> want our extensions branch for instance, you'd merge from "extensions". If
> you want it to incorporate the 1.6 changes before they land to "master", you
> might merge from "release-1.6".
>
> The key point is that your branch for your own builds can merge from any
> number of branches, any time those branches merge, and those branches can
> merge from what they need to ("master" for example).
>
> You probably shouldn't ever commit to any of the upstream branches, though,
> as those should be reserved for changes coming from our GitHub repository.
> If you've been doing this and want to try the "vendor" approach, it won't be
> hard to switch over. Just rename your branch:
>
>     $ git branch -M master vendor
>     $ git checkout -b master origin/master
>
> That'll rename "master" to "vendor" and then create a new "master" branch.
>
> Hope that helps?
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board -http://www.reviewboard.org
> VMware, Inc. -http://www.vmware.com
>
> On Mon, Apr 5, 2010 at 9:21 PM, Jan Koprowski <jan.koprow...@gmail.com>wrote:
>
> > Thank You very much for answer :)
>
> > To the POST hooks :) or URL hooks. IMHO there are many ways to pass
> > arguments to hook like this. I think this will be good to have
> > something like "method" argument in hook calling which could be
> > similar to jquery.ajax argument. Which means when we call hook we
> > could determine how arguments hook will be send:
> > POST, GET or JSON or something else. My little suggestion :)
>
> > I belive this mechanism will be good enough to customize reviewboard
> > external integrations :]
>
> > About branches. Now I see one problem.
> > I'am providing some features to ReviewBoard (more fixes for ClearCase
> > then features but features will be there also) and I post reviews for
> > it. But there are some features which  have sens only for my company,
> > and I just keep them in another branch without posting it public.
> > Which branch I should use? Now I use default one from github. Now I
> > see there is another branches where some of features which I need
> > (maybe which I implement by my self) are present :) I don't want
> > implement features which is available now. No I'am a little bit
> > confused which branch I should use to have stable ReviewBoard, may
> > post reviews and write patches and get unpublic features not provide
> > in ReviewBoard yet? Is there any branch like this? :D
>
> > Thank You for Your answers :)
>
> > On Apr 6, 5:14 am, Christian Hammond <chip...@chipx86.com> wrote:
> > > Hi,
>
> > > We have a few things planned and in development for the level of
> > > customization you guys want.
>
> > > 1) We have some things that will be in the 1.6 release (it's actually
> > > written today, just isn't scheduled for 1.5) for WebHooks, which allow
> > for
> > > calling external scripts (technically, doing an HTTP POST to a URL) on
> > > various events. I can't remember exactly if Submitted or Discarded hooks
> > > into this, but it could be made to if it doesn't.
>
> > > I'll probably create an early 1.6 branch for development before long
> > which
> > > will have this. You could make use of this branch if you want to use this
> > > sooner, though you'd have to maintain your own packages internally.
>
> > > The way it works is that you have a script hosted on a web server
> > somewhere.
> > > It could be PHP, Python, whatever. It responds to an HTTP POST and knows
> > how
> > > to take a certain payload and return certain information. You would then
> > > reference this URL in the admin UI for different events.
>
> > > 2) It's quite possible we'll have some level of theme support (perhaps as
> > a
> > > Summer of Code project) for letting admins configure their own templates
> > by
> > > basically just overriding parts that they need. That's not happening for
> > > 1.5, but maybe 1.6.
>
> > > 3) We're working on extensions support. There are branches for it today,
> > but
> > > it's nowhere near ready for production use. However, it will allow for
> > more
> > > advanced customization without modifying Review Board.
>
> > > As for the suggestions for changing how settings works, I'd actually
> > rather
> > > do nothing about this right now. I feel that while we'd get a lot of
> > > flexibility, it would increase our support burden, and there's rarely a
> > case
> > > where this would need to be used anyway. The customizations you're
> > > referencing will be there in a much easier way in future releases, and if
> > > you really need to specify your own TEMPLATE_DIRS, you can define it
> > without
> > > inheriting and just shove the old values in there. Much easier than a
> > whole
> > > new import mechanism :)
>
> > > Christian
>
> > > --
> > > Christian Hammond - chip...@chipx86.com
> > > Review Board -http://www.reviewboard.org
> > > VMware, Inc. -http://www.vmware.com
>
> > > On Sat, Apr 3, 2010 at 12:11 AM, Jan Koprowski <jan.koprow...@gmail.com
> > >wrote:
>
> > > > Hi!
>
> > > >  I'am start using reviewboard and need some customizations:
> > > >  1) I need hooks run after Submited or Discarded
> > > >  2) Add custom footer, change logo, title
>
> > > >  First thing is a way to customize some layoutes. I know how I can do
> > > > that now:
> > > >  * copy templates from reviewboard to my folder
> > > >  * set in my settings_local TEMPLATE_DIRS to my directory and
> > > > oryginal directory (for example symlink somewhere inside my instance
> > > > created by rb-site)
> > > >  but this option have one limitation. Upgrading my ReviewBoard need
> > > > to check is modified by me templates doesn't change... hmmm.
>
> > > >  My idea is made some modifications in settings_local which allow not
> > > > only overwrite existing settings but modify it.
> > > >  My first try looks like:
> > > >  settings_local.py
> > > >  -----------------------------------------------
> > > >  import reviewboard.settings
> > > >  TEMPLATE_DIRS = (
> > > >      r'/my/custom/dir'
> > > >  ) + reviewboard.settings.TEMPLATE_DIRS
> > > >  -----------------------------------------------
> > > >  but this doesn't have effect. I guess problem in import recursion.
> > > > settings_local import settings and settings import settings_local.
> > > > Python make it and modify TEMPLATE_DIRS but Django doesn't catch
> > > > this.
>
> > > >  So the second shoot is change some ways.
> > > >  * settings.py > settings_default.py
> > > >  * settings_local.py
> > > >  -----------------------------------------------
> > > >  from reviewboard.settings_default import *
> > > >  [...
> > > >  ...
> > > >  ...]
> > > >  some custom modifications
> > > >  * settings.py
> > > >  -----------------------------------------------
> > > >  try:
> > > >     from settings_local import *
> > > >  except:
> > > >     from default import *
>
> > > >  some neccessery checks and customizations
>
> > > >  This is the way (i think) good enough which provide some features
> > > >  1) We have our default values
> > > >  2) User can change anything in settings_local. Overwriting is only
> > > > one option. There can be also modification! They can add some custom
> > > > template directory before templates from reviewboard (and create their
> > > > own templates) or not :] Second grate benefit is way to add some
> > > > custom plugins (MIDDLEWARE_CLASSES or APPS) which allow to do many
> > > > greate things.
>
> > > >  Unfortunetly I don't know how this looks with merging with Django
> > > > source tree so :] there is second option (IMHO a little bit worse then
> > > > first one)
> > > >  At the end add loop which check settings_local under MYRB_PRE_ and
> > > > MYRB_POST_ prefixed variables and add/append values to existing once.
> > > >  for variable filter(lambda s: s.startswith('MYRB_PRE_'),
> > > > dir(settings_local))
> > > >      [...]
> > > >      globals()[varname] = variable + globals()[varname]
> > > >  for variable filter(lambda s: s.startswith('MYRB_POST_'),
> > > > dir(settings_local))
> > > >      [...]
> > > >      globals()[varname] = globals()[varname] + variable
>
> > > >  IMHO first option is much more clear and flexible and bettter
> > > > designed then first one. What do You think? I can prepare review for
> > > > this concept.
>
> > > > Greetings from Poland!
> > > > --
> > > > Jan Koprowski
>
> > > > --
> > > > Want to help the Review Board project? Donate today at
> > > >http://www.reviewboard.org/donate/
> > > > Happy user? Let us know athttp://www.reviewboard.org/users/
> > > > -~----------~----~----~----~------~----~------~--~---
> > > > To unsubscribe from this group, send email to
> > > > reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com>
> > <reviewboard%2bunsubscr...@googlegr oups.com>
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/reviewboard?hl=en
>
> > --
> > Want to help the Review Board project? Donate today at
> >http://www.reviewboard.org/donate/
> > Happy user? Let us know athttp://www.reviewboard.org/users/
> > -~----------~----~----~----~------~----~------~--~---
> > To unsubscribe from this group, send email to
> > reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com>
> > For more options, visit this group at
> >http://groups.google.com/group/reviewboard?hl=en
>
> > To unsubscribe, reply using "remove me" as the subject.

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Reply via email to