Simon Ward wrote:
>
>
> I would encourage you to get away from that mentality, and rather commit
> as soon as possible, whether or not the task is finished. If that would
> break policy on the branch you are working on, then you can always
> create a new branch for the task, and later merge it back into the main
> branch.
>
> I have started to get into the habit of doing this, however, I realise
> others may find it difficult, since you have to actually remember to do
> the commit, and you may even have to break out of your environment (for
> example, if there is no shortcut key, or nice little button).
>
> Donn M. Seeley writes in
> http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=69&page=6
>
>
> ~ In my experience, the worst problems are created by engineers who
> don't want to check in their code until it's perfect and by those who
> resist making informative log comments.
Thanks for the exhortation Simon,
You hit it on the head. I am a bit of a perfectionist and certainly
guilty of not checking in often enough. I guess that applies to the log
too. That is why I posted. In one sense the code is the best log, I mean
you can always look at the diff. If you are trying to unwind because you
decide that the current implementation is really not achieving the
design objective then it is nice to have clean logs. I guess I am really
seeing that I should not be so hesitant to branch. I have always thought
of branches being different development directions off the same trunk
and that doesn't make sense to me early in the project life cycle. This
thread has had many comments referring to branching so maybe that is the
"best" practice.
Thanks again to all the posters
-Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 17 02:36:00 2005