Phyrefly wrote:
> (forgot to reply all, again - Fwd-ed)
>
> This is starting to sound like an argument for not using source
> revisioning at all.
>
> "If the developer doesn't comment a revision, we'll never know why he
> made that change"
>
> Hell, let's all pack it in, and never write another line of code, just
> in case someone creates a bug, or someone uses the application to do
> something we didn't intend.
>
> <Serious mode on>
> The alternative to "frankentags" is to checkout different versions of
> different things, and commit them all as one revision, tag that, then
> get the original HEAD code and re-commit it over the top. How is that
> more useful? Surely this contains _less_ information, as we don't
> even know what revision that tagged code came from, much less why!
>
The alternative is to use branches as change sets and merge from the
branches to get the features and fixes you need for a release. I don't
like committing changes directly on the trunk (which is what complex
tags encourages).
The bookkeeping for complex tags breaks down when you have to perform
multiple commits for a single change. For example, I fix bug A, commit,
then add feature X and commit. Now, I find the fix to bug A still has an
issue. So, I make more changes and commit. With complex tags, I would be
unable to easily select only the bug A fix for a release; I would have
to check out the latest fix and then reverse delta the feature X change.
I also no longer have a way to easily tell what changes were made to fix
bug A.
-- John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 17 15:27:35 2006