On Mon, Feb 20, 2012 at 8:31 AM, Ulrich Eckhardt <
ulrich.eckha...@dominolaser.com> wrote:
> I'd generally update regularly, more than once a day even. However, when
> I'm in the middle of working on something, I don't want other people's
> changes to come in, so I defer updating. Before committing though, I must
> make sure that my changes don't conflict, so I have to update first, then
> test again, then commit.
>
> That said, committing at the end of a work day (I'm not sure if that is
> what you meant) is a bad idea, as it conveys zero useful information. If
> you are concerned about data loss, then you need a backup solution in
> addition.
>
Again, depending on the relationship of the changes being done
concurrently, you can separate the effects of committing and sharing the
changes with branching. That is, you can make a branch for each workspace
to check out separately so they can commit anything or any time they want
without the changes being picked up by the others, and then the work can be
merged when the changes are complete. Look for descriptions of the
'feature branch' style of working. Personally, I think it is usually better
to do new development on the trunk to take advantage of each others' work
and fix conflicts sooner rather than later, but it really depends on the
nature of the work. Also, if the work has 'release' points with
feature-freezes and stability testing, look at the 'release branch' style
that lets more drastic changes continue on the trunk after you make the
initial release cut.
--
Les Mikesell
lesmikes...@gmail.com
