Re: [RFC] teamGIT bonjour support

2009/8/28 Abhijit Bhopatkar [off-list ref]:

Hi,

After a long pause in the development, i am back to drawing boards for teamGit.

Ever since i adopted git as my preferred version control system for my
teams, I had this tough time keeping up with every one. Of course this
is a GoodThing(TM) since this means pace of development is rather
good. But it has its usual problems of forcing everyone to religiously
publish _AND_ keep rebasing on main branch every so often. Also my
major problem is that we discover conflicts only _after_ a developer
tries to rebase his work, typically (by design) after he has fully
coded and tested a feature.

What sort of time frame are you talking about?  How long are your
sprints, or however you partition your work.

I can't help but feel the problem should be solved elsewhere.  Do you
have daily scrums?  Everyone should know, roughly, what everyone is
doing.  If you are using 2-3 week sprints (or however you partition
the time) and everyone is roughly aware of what everyone else around
them is doing, there shouldn't really be so much of a problem.

The current way to get around this is shouting aloud before you start
working on a new feature/file/section.

How do you allocate the features in the first place?  At the start of
a sprint?  If so, it should be the person in charge of that that
should see if there are going to be conflicts.  If you don't have
sprints, then how do you divide up tasks?

John