[SR-Dev] [Serdev] sip-router: modules & repositories

[Jan Janak]

On 26-02 02:43, Andrei Pelinescu-Onciul wrote:
> On Feb 26, 2009 at 02:15, Jan Janak <jan at iptel.org> wrote:
> > On 24-02 12:13, Andrei Pelinescu-Onciul wrote:
> [...]
> > 
> > >                  - if someone working on the ser_30 branch (for example)
> > >                    finds a problem in the core and wants to fix it, it
> > >                    has to do it on the master branch.
> > 
> > Switching branches in git is not that convenient if you are in the middle of
> > some bigger changes and you have lots of uncommited changes. That practically
> > means that you would have to clone the repository again, discard your local
> > changes in the new clone and checkout another branch (master). Then you need
> > to switch back to your original repository and merge the changes you just did
> > on the master branch.
> 
> That could be done much more easier with git stash (I use it a lot):
> git stash save "my changes"
> git checkout master
> ...
> git stash pop # applies saved changes
> 
> Moreover I don't expect that the situation in which you are working on
> some project specific branch and you have to do some changes on the
>  common part will occur so often (it does now, because we still need to
>  do frequent "adjustments" as testing/integration progresses, but it
>  will change).
> 
> Note also that having 3 repos will not help here (you'll still have to
> do common part changes on the sip-router repo/main) and I don't think
> you could use git stash in this case (unless you import all into the
> same local repository).

I've tried git stash but it does not integrate well with my emacs editing
workflow. I'm much faster with multiple repositores because I can access them
all at the same time from emacs.

Anyway, I feel easy about switching to branches inside one repository and I
would not impose any restrictions on the master branch now, let's be open and
see if we can get away with it.

I should also add that our current workflow is most likely more difficult than
it will be in the future as we consolidate our stuff. We now have all the
cvs/svn synchronization going on, in various repositories, filtered and
unfiltered. That won't be needed in the future (at least not that much).

   Jan.