At 06:30 PM 11/14/2001 -0600, Ben Collins-Sussman wrote:
>Bruce Atherton <bruce@callenish.com> writes:
> > If I understand you correctly, though, if you want to move a tag deep
> > in your wc, you have to do something like this:
>
>Nope, I think you're confused.
Well that wouldn't be much of a surprise, and I'd be glad to learn that I
was. But what you tell me below doesn't enlighten me as to where my
confusion lies.
>If I want to tag some really deep directory in my working copy, I
>don't need to cd in there at all. It's optional. I can just specify
>the deep wc path as the first argument to 'svn cp', or I can cd in and
>specify '.' as the first argument. There's no difference.
Sorry, I wasn't suggesting that you HAD to. I was just using the current
directory to illustrate a point.
With CVS, there is a real benefit to being in that directory (which a
developer who is working on this code is likely to be doing anyway). The
reason is that the CVS/Repository file keeps track of how that directory in
the working copy maps to a directory in the repository. Because of that, I
can simply type:
cvs tag -F MYTAG myfile
no matter where I am in my working copy, and I know the correct file and
revision will get that tag. This is very convenient, and far less error
prone than trying to specify the tag using the CVS rtag command, which
ignores your working copy entirely:
cvs rtag -F MYTAG some/really/deep/directory/path/I/am/using/myfile
Now, it appears to me that the tagging solution offered by the svn cp
command is always going to look a whole lot more like rtag than tag, which
really would be a usability problem. This is happening because the mapping
back to the repository that happens in .svn/dir-wcprops or .svn/entries (I
haven't looked at the code to determine which) is not mapping to both the
original location AND some equivalent location within the tags directory.
Nor does the client have any clue (by design) as to how to perform the
mapping automatically.
>Secondly, I can "copy" my wc directory to any location I want on the
>server. The 2nd argument can be any old URL I want, shallow or deep.
>It just depends on how I've laid out the server. Remember, a tag is
>just an ordinary directory in the repository filesystem -- it could go
>anywhere. (If this is news to you, read the design spec, or the end
>of the "SVN for CVS users" doc.)
No, not news at all, but I don't see how that will deal with the issue I am
raising. I'm not talking about tagging a tree of the files in a release,
I'm talking about tagging files individually or by directory. And the
flexibility you are talking about is not going to be a benefit for
developers who tag files regularly, in a systematic way, many times a day.
Let me give you a use case that I believe is probably pretty common,
perhaps that will help.
You are working with a team of developers who have two tags at their
disposal (three if you include HEAD). They check out some small portion of
code to work with, and when they have tested it enough on their sandbox
they tag it as being ready for integration testing, say with the INTEG tag.
Any file with the INTEG tag gets automatically checked out and built on an
integration machine and the results stored on a shared drive that every
developer uses (their local code overrides the shared code, if present).
Agile Methodologies often use this type of rapid integration, for example.
When the developer considers a set of their changes to be feature complete
and ready to go into production (passing through QA first, of course), they
put a PREQA tag on the revisions that are tagged INTEG. After this point
the release manager decides whether it actually is going into production
and assigns a tag reflecting the release number.
As is all too often the case, QA finds a bug that must be fixed before the
code can be promoted. Fortunately, the fix is easy. The developer goes into
their working copy, makes the change, and tags the file INTEG.
Unfortunately, in order to tag the file so it can go back through the
promotion scheme, he has to type a phenomenally long string to make that
happen, perhaps several times for different files. And if the integration
build is successful, do the same thing over again to tag it PREQA. This is
a pretty big burden if you are fixing dozens of small bugs in a day, larger
than fixing the bugs themselves. I sure wouldn't want to do it.
Now, perhaps the problem is that I am not really "getting" the brave new
world, that rather than using tags for code promotion in Subversion we
should be using properties or something similar. Or perhaps there really is
a simpler way to specify the tag directory mapping using the cp command
than I am realizing.
All I'm saying is that I believe it would be quite desirable if the
solution for tagging that Subversion ended up with did not force so much
typing, since there are environments where it happens frequently.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:48 2006