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 at http://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