Re: Subversion tagging

> Yes, internally there is no "per file revision". Functionally however,
> there very much is. This is particularly notable in mixed revision
> working copies. Copy that WC to a "tag" and you have a snap shot
> of that mixed revision. This effectively gives you per-file revision
> functionality. That's the entire point of WC to URL copy ("tag").

You know that /tags/TAG_A/dirOne/FileA.blah is a copy of /trunk/dirOne/FileA.blah, and I guess the repository knows that one was copied from the other. But it is a logical leap to assume that you know have a per-file revision. Once the TAG_A file is copied, you have two different files. Unless something changes (subversion internally tracks the two files are related by way of a copy and this link is maintained until either file is deleted from the repository), they're two different files to the repository and no matter how much you want it to know what you know, it won't. So, while you know there's a per-file revision functionality, it really doesn't exist in the repository.

> This is all well and good until someone wants to report based on such
> tag states. Since SVN's "tag" is really a copy you end up with new
> paths and new revisions. This makes it a huge PITA to report the
> differences from one tag to another (not the line by line diff which
> is easy, but the logs for the commits the differences actually
> represent).

Kind of a different argument from the one originally starting this. It is a pain to look at all differences between all versions of a file, because of the lack of internal linking between the files. However, I'd be more inclined to think that keeping the internal links between copied files within the repository is more likely provide a better report than attempting to provide CVS-like tagging in Subversion.

And as far as branching not being relevant in the "Internet Age" as compared to shrink-wrapped software, sounds more like a rant against how your production environments are set up, versus ivory tower process. We quite easily use branches to control what goes out, and we quite happily have multiple releases. But, we don't expose our source control repository to anyone consuming our software (we have a controlled release process which generate binaries which are downloaded on request).

However, even if we were exposing a Subversion repository to the consumers (instructing them to update from it to use new releases), it would make a alot of sense to me to never tell them to use files from the trunk, but a branch directory. Changes that go into the trunk would never go out to a production site, only those that are committed or copied to the branch. Consumers would only need to know when to update from the branch. As such, a fix only requiring a change to a single file would then only require that single file to be copied or merged to the branch, ensuring that changes to other files which aren't ready for production stays where it should.

For me, I'll happily continue using branches to control when software goes out to production sites, even in this day and age. I'll always argue that using the trunk to cut/provide releases is always more dangerous and/or tedious than using branches (Either in Subversion or CVS).

Send instant messages to your online friends http://au.messenger.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 23 00:11:27 2007