Re: Tagging changesets

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".

[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.

-----Original Message-----
From: Les Mikesell [mailto:lesmikesell@gmail.com]
Sent: 25 August 2006 19:06
To: Holger Stratmann
Cc: John Doisneau; users@subversion.tigris.org
Subject: Re: Tagging changesets

On Fri, 2006-08-25 at 17:06 +0200, Holger Stratmann wrote:
> Use Beyond Compare or whatever to "mark" your
> changes as belonging to feature A or bug B before you commit. That's not
> so nice from a Subversion perspective, but at least you'd keep your
> "existing functionality" (i.e. a text editor?!) in those cases. I think
> the overhead for this is, was and will be significant, so it's much
> better to finish A before starting B if you really want to "track" it
> separately.

Or unless you have a strict policy of only allowing completed work to
be in the repository (in which case you should probably have branches
for ongoing work anyway), just commit the partly complete work on A
before changing anything for B, and say so in the commit message. You
are going to have to deal with things committed in multiple stages as
soon as someone makes a mistake or takes several tries to get something
finished anyway.

-- 
  Les Mikesell
   lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd.
This email and any files transmitted with it are confidential and 
may be legally privileged. It is intended solely for the use of the 
individual or entity to whom it is addressed. If you have received 
this in error, please contact the sender and delete the material 
immediately. Whilst this email has been swept for viruses, you 
should carry out your own virus check before opening any 
attachment. Celoxica Ltd accepts no liability for any loss or 
damage which may be caused by software viruses or interception 
or interruption of this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org