Re: Issue a command for more than one folder

> CVS doesn't handle relative paths quite well.

I've read that in discussions before. What does it mean in real life?

Is it that, for a module "Module" located in, say, "C:\Projects", a

(A)
cvs <some-command> Module (in C:\Projects)

differs from

(B)
cvs <some-command> (in C:\Projects\Module)

in function? Or is there another case I'm unable to imagine?

Currently, WinCvs issues the (A) version when a folder is selected. 
The command is supposed to use the CVSROOT and module name stored in 
C:\Projects\CVS and will fail if C:\Projects is not a sandbox itself 
but merely a collection of sandboxes. I don't see (and didn't ever 
expierience) a difference between issuing two commands

(A1)
cvs <some-command> Module1 (in C:\Projects)
cvs <some-command> Module2 (in C:\Projects)

and issuing one command

(A2)
cvs <some-command> Module1 Module2 (in C:\Projects)

. Are there bugs in CVS that prevent (A2) from working properly in 
all cases?

My point is: If WinCvs uses alternative (A) anyway and this is not 
supposed to be changed in the near future, why not allowing (A2) (if 
they behave identically)?

We could make it an option like "Smart Sorting" :-) A checkbox 
like "Allow multi-folder command" that, when enabled, would hand the 
responsibility for bad behavior over to CVS. Disabled by default. If 
disabled, a multi-folder command would print a warning to the console 
with a reference to above check box.

Another option would be to check the CVSROOTS and module names in 
Module1\CVS and Module2\CVS and issue (A2) if they're equal, (A1) if 
not.

> It works better for some 
> commands than for others. We had a lot of reports about failed "cvs 
> add" in particular. Things can go wrong with commits as well 
> and you don't want to take your chances here.
But what can possibly go wrong with Diff, Query Update or even 
Update? 

> For multifolder selection the 
> best so far was issue one command per directory. This is what I am 
> doing in CvsIn and it works pretty good. 
That would be (A1). It's a "sure shot" but unnecessarily slow in many 
(if not most) cases. Again: How could CVS possibly misinterprete 
relative paths when using the same CVSROOT and when module names in 
the sandbox match those in the repo? I think this is by far the most 
frequent case.

> The next best thing would be to run one command per folder. ...
> Fire-and-forget would make that 
> easy because we would just send per-folder command into the queue 
and 
> the background thread would take care about the rest. 
I've looked at the code around launchCVS -- I see a lot of work to do 
for that. All platform-dependent and deadlock-prone...

> It may be possible to implement per-folder even now, but that may 
> complicate later implementations.
We can have it all easily right now:
- Add a new CCvsConsole child class CDefaultConsole that writes its 
output to the console. This, when used, makes calls to ::launchCVS 
synchronous.
- Add a class CCvsLauncher with a function launchCVS that takes the 
same arguments as the global function. This class will collect the 
arguments for multiple CVS runs
- Functions in CvsCommands.cpp that don't care about CVS's result 
call a local CCvsLauncher instance's launchCVS function. Minimal 
changes to existing code.
- In the destructor, CCvsLauncher launches the collected CVS commands 
one by one, using a CDefaultConsole for every command but the last
- When "Fire and forget" is implemented, change CCvsLauncher's 
implementation to launch the CVS commands early and not upon 
destruction
- Drawback: No commands but "Stop CVS" available while the CVS 
commands run; can be changed (at least for WinCvs) by having an own 
message pump in ::launchCVS.

What do you think?


Cheers,

Kirill






 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/cvsgui-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/