Hmmm. It's been a long time since I wrote that comment! Peter, I don't
know that I disagree with you, as I agree that consistency is really
important, but I don't know that this is being entirely inconsistent
(i.e., "one dir == do this", and "more than one dir = do that"). I
guess it depends on how you look at it.
I for one rarely use co -d with multiple directories, so I don't think
that I have particularly strong opinions on the color of this
bikeshed. :)
-Fitz
> 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.
---------------------------------------------------------------------
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