Post by kaczorojCVS 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.
Post by kaczorojIt 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?
Post by kaczorojFor 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.
Post by kaczorojThe 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...
Post by kaczorojIt 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:
cvsgui-dev-***@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/