> -----Original Message-----
> From: John Doisneau [mailto:jdoisneau@gmail.com]
> Sent: Thursday, August 24, 2006 9:48 AM
> To: users@subversion.tigris.org
> Subject: Re: Tagging changesets
>
>
>
> 2) Before "committing" our changes (it is not really a commit since
> we are not using version control software but it is equivalent) we use
> a "differencing" software like Beyond Compare: it shows all the
> changes made for both tasks and allows in place editing - we then use
> the in place editing feature to add a little tag written like a
> comment like /* FCT_A */ or /* BUG_B*/ at each block of code which was
> added or modified. And usually at the top of the file where the most
> changes have been made we add a longer description of the feature,
> like
> /* FCT_A: Developer DDD - mm/dd/yy - Implemented functionality A */
>
> Does that make sense? Does that bring more comments?
What's the benefit of tagging each code block? In theory, you start at
point A and that you have a set of bugs/changes that need to be in point
B. All you care about is whether you can get to point B with the full
set of changes. You shouldn't care if an interim version of a file has
a combination of bug1 and bug2 fixes.
However, if bug1 won't make it to point B and has to be removed from the
release, then you will care if bug1 and bug2 cohabit in a single file.
Tracking the bug fixes down to individual code segments is nice at that
point. However, because of business logic, code dependencies, etc., you
will need a human to remove the code. The human should know enough to
correctly unravel bug1 from the release without having pre-tagged code
blocks. (The commit messages should have the bug numbers listed in them
so the human knows where to start.)
Long story short, I would think that the gains of tagging individual
code blocks do not outweigh the cost, since tagging code blocks is
useless overhead until you need to rip code out (which should be rare.)
If you're ripping out code often enough to justify the effort of tagging
code blocks, then your dev process is in serious pain (or is very
unique.) IMHO.
OTOH, it's a great way to enforce code reviews, but I would still want
to code review a milestone or 'completed' file and not every single
interim version of a file.
> 2) Before "committing" our changes (it is not really a commit since
> we are not using version control software but it is equivalent) we use
Then why post to the Subversion mailing list? =P
We have a product that contains code in a database (aka a single global
shared working copy) but we use Subversion to track code changes (a
commit will grab the code from the db, put it into a file, and checkin
the file. A checkout will 'svn lock' the file so folks know that
someone is working in that part of the db.)
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 29 16:51:15 2006