L. Wayne Johnson wrote:
> I'll admit that I don't understand this use case, maybe because I only use
> svn for source code projects (all the things under source code control work
> together.)
>
> If all the files work together it not clear to me how you can
> know the 'quality' of a single file in the collection since they are all
> interrelated. And even if you can there is no guarantee that the file will
> do what you want when matched up to files of a known 'quality' from a
> different time. To me, the quality of a single file just doesn't count. My
> customer doesn't care whether or not foo.c works correctly or not. My
> customer only cares that when he runs my software he gets the "right
> answer."
Your term "source code projects" is a bit broad. The lifecycle of
a product intended to be shrink wrapped is *drastically* different
from that of a web based app or internal company app. Yet they
are all "source code projects".
Your bias here appears to be toward the shrink wrap lifecycle (as
are most (misnamed) "best practices" SCM guidelines). A typical
modern web app doesn't naturally follow anything remotely close
to that lifecycle.
Other paradigm like XP and OOP can quickly show problems in the
"standard" shrinkwrap model as well, but for different reasons.
For XP branching much or at all is counterproductive to the
practice ("shrinkwrap product" or not) as it pushes integration
down the road. For OOP the modularity of the code base can often
mean that changes are so isolated that yes, the status of small
chunks of the tree matters independently as well as a whole.
> The original poster asked for a way to pick a bunch of files from different
> times in the source code development without having to go pick them all one
> by one. I don't understand how you can pick a bunch of unconnected things
> without picking each one by hand.
cvs rtag -r OLD_STATE NEW_STATE my_module
cvs rtag -F -r HEAD NEW_STATE my_module/bump_this_file.txt
The result is NEW_STATE is everything OLD_STATE had, plus one file
updated. A common use case is that OLD_STATE might be QA_BUILD_4
and NEW_STATE would be QA_BUILD_5.
> Subversion doesn't keep track of files, it tracks groups of files.
And a CVS style tag *is* a labeled group of files (and revs). It's
much the same as if you used copy in SVN from a WC to a tag/my_tag,
just much saner for anyone looking at the file's history. In SVN
when you create one tag from the location of another you're really
screwing the hell out of the file's history. It's very easy to
end up look at a tag/release_1.2 tagged file and finding you need
to recursively lookup it's ancestry *HUNDREDS OF LEVELS* to find
the *actual* home of it:
rel_1.2 (copied from build_425)
build_425 (copied from build_424)
build_423 (copied from build_422)
......
build_15 (copied from branch/branch-1.2)
SVN does a great job of tracking the current state of the universe.
Where it fails badly is tracking any other status besides latest
and far worse still on reporting history (especially summary history
from one state (say, qa build) to another. It's a huge drawback
for most any modern web based application.
Another use case for real status labels is in managing the merge
process. CVS tags work great for tracking the state of merges
including partial merges. -In a large app it's not uncommon for
a major merge to take a while and be done in logical chunks. CVS
tags allow you to mark the state file by file or directory by
directory as you progress through the merge.
Code reviews are another great use for status labels, again because
you're rarely able to review the entire tree in one shot. Labels
in this use form a kind of book mark.
> It seems
> to me that this was a conscious design decision and that with source code
> projects, this is what you really want to do. I am not an expert in how svn
> works but from what I understand it seems that adding support to track files
> individually would be difficult at best.
Actually it'd be trivial, at least functionally. Unversioned
properties is the obvious location for this information and that's
already in the SVN filesystem).
The real issue would be performance. SVN does what it calls "tags" the
way it does not because CVS tags weren't functionally a very useful
feature, but rather because such per-file-rev state tracking is a
major performance hog. Instead of being clever and finding a way to
keep this incredibly useful feature from CVS (and most SCM systems),
the SVN devs came up with this copy/branch idea. While I'm sure the
devs thought they were being incredibly cleaver, in reality it's a
cop out that doesn't actually solve the problem.
In CVS I can:
cvs log -r FROM_TAG:TO_TAG my_module
In SVN I can't. This obvious feature simply is missing from SVN wholesale.
There is "svn log -r10:20 my_module/branch/some_branch", but this is
not equivalent in the slightest. Who says FROM_TAG is rev "10" on every
file? Heck, who says it even is from the same branch? SVN supports
mixed revision/location tagging and so SVN "tags", just like CVS tags,
can translate to a collection of files/directories of mixed revisions and/or
off different branches. In the real world there are many valid uses for
this which is why both support it. The difference comes in that CVS can
actually report on such sets (mostly sanely) while SVN can not at all,
additionally SVN must use a working copy to create such sets which can be
hugely expensive while CVS allows you to do it all remotely.
And of course...where do I keep track that "10" and "20" are the revs I care
about? Some "numbers_that_matter.txt" text file? You can use SVN's "tags"
again, but with difficulty. -You can't look at a given file and see how much
of its history has been merged and when (there's no "copied to" support, only
copied from).
> There are some people that use subversion for tracking unrelated documents.
> I don't think that Subversion was really not designed to do this.
A configuration is inclusive. If you are only able to track one section of
a configuration then you are not a configuration management tool.
-Byron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 22 20:50:46 2007