Rob Hubbard wrote:
> Take care with committing "partially complete work". This needs some qualification...
>
> Don't use SVN (or any other version control system) as a means of backup. If you need to back work up, do something else (e.g. copy to CD or tape, or to a server).
>
> If you commit partially finished work (whether or not in a branch), then the changes should always satisfy certain minimum requirements:
> * they should compile (or display correctly, or some equivalent);
> * they should be well-defined.
>
> This is akin to "completeness" and "consistency".
>
>
These are good points. Bear in mind that this has less to do with the
specifics of how Subversion works, and a lot to do with your policies
about how you use your version control system. Whether you allow
partly-completed work in the repository is a choice you make. Also what
constitutes "complete" and "consistent" is up to you and not
Subversion. I agree with Rob's advice that there should be some minimum
level of quality before checkin, such as requiring a clean compile and
perhaps unit testing.
In our repositories, it's OK to check in partly completed work. We just
include specific comments in the commit message about "partially
complete", or similar that indicates clearly that the change is
incomplete. We do this sometimes if the partly completed work is in a
stable state, but the next phase of work is likely to break things, and
we want to be able to undo that last step. The final commit includes a
comment that the change is finished....or of course, we stop using the
branch and just merge everything to where we want to integrate the change.
This works for us because we do development on branches and then merge.
We have to make sure we include the complete range of revisions that
covers all the steps of the work. This is evident based on the
comments. If your development is on a shared branch, this isn't going to
work.
If one has to work on two changes at the same time, we use two
branches. Intermixing changes for two different issues is too hard to
handle. It's easier to do more small merges than to try to keep things
straight, and this helps us to capture the history of each change within
Subversion itself.
Our branches are personal, so we don't have collisions between
developers until we specifically invite them with a merge or a rebase.
That helps a lot.
> [By "well-defined", I mean that the changes are for a single, self-consistent, describable part of the overall work.]
>
> Breaking a large task into smaller well-defined subtasks is usually a good idea, however. It is easier to review work if it is broken down in this way.
>
> Sometimes changes can obscure other changes. For example, if a few lines of code are functionally changed, but a variable is also renamed, then those rename changes make the functional changes difficult to see. You might consider committing the two separately.
>
> If there is a requirement (or just desire) to ensure that all such subtasks are contiguous in the repository, then the work will need to be done via a branch and merge.
>
> Rob.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 29 17:01:37 2006