I sent this reply just to Kevin by mistake - sorry about the duplication,
Kevin. I've added some more comments at the bottom.
On 2001-08-24 11:07:38 Kevin Pilch-Bisson wrote:
>On Fri, Aug 24, 2001 at 10:11:28AM +0100, peter.westlake@arm.com wrote:
...
>> So I want predictable behaviour, which means I need a way to get
>>
>> foo/A/one_mississippi.txt
>> foo/A/two_mississippi.txt
>> foo/A/three_mississippi.txt
>>
>> Then I can do things like
>>
>> svn co -d foo $projects # but a different syntax to -d?
>> munge foo/*/Makefile
>>
>> and it works even if $projects only has one entry.
>
>
>why not make your script
>for p in $projects; do
> cvs co -d foo/$p $projects
> # perform your mungining
>done
>
>Then you get perfectly predictable behaviour regardless of the number of
>projects.
Well, yes, but that's precisely the kind of added complexity
that I want to avoid. It's a kludge to get round a bad design.
I have to remember that the command has "non-linear" behaviour
and program around it.
It's very like the behaviour of cp, copy, and xcopy on Unix
and Windows, where "copy Dir1 Dir2" will either give you
"Dir2" or "Dir2/Dir1" depending on whether or not the destination
exists. It's a copy command that isn't idempotent! This is another
case where I want to command to do exactly what I tell it, nothing
more, nothing less, no second guessing or context dependency.
Heuristic shortcuts are all very well for interactive use,
but for programming I want an *algorithm*. Even for interaction,
too much adaptive behaviour can be confusing. It's like parsing
quirky syntaxes: if it's hard for a program, it's probably hard
for people too.
Another way to look at it is to say that I want to specify
the *result* of an operation, not the details of how it is
carried out. The co and cp examples give different results
depending on external factors; you can't look at the code
and know what the state of the system will be after the command.
This, I assert, is a bug.
Furthermore, with separate checkouts in a loop there is scope
for someone to check in a change in between. The projects won't
have the same revision number. I don't know if this syntax works
for commits, but if it did, the projects would no longer be
checked in as part of a single atomic transaction. Even if this
doesn't apply to CVS or Subversion, it serves as a hypothetical
example of the problems of this approach.
Peter.
---------------------------------------------------------------------
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:36 2006