#731 Problems with flat commit

[Henri Volk]

Hi,

just tried the new 1.3.18.1 and I have the following
problem. SInce now the CVSROOT can be set for
checkout (what's that for again? ;-)), commit is not
working when the tree position is not on the directory
where the file is located and if flat file mode is active.
Message:

cvs -q commit -m "no message"
common\lib\microsoft\fvscutils_vc7.lib (in directory
S:\data\)
cvs commit: No CVSROOT specified! Please use the `-d'
option
cvs [commit aborted]: or set the CVSROOT environment
variable.

Could become annyoing for bigger projects....

Thanks
Henri

[Oliver Giesen]

Logged In: YES
user_id=158827

"SInce now the CVSROOT can be set for checkout (what's
that for again? ;-))"

Well, how else should CVS know which repository to check
out from?! WinCvs no longer has a global CVSROOT
preference so this is the place where it's actually needed.
BTW: It was possible to override the CVSROOT for a single
command before 1.3.18 as well via the "General" tab and
the "force using current CVSROOT" option.

"commit is not working when the tree position is not on the
directory where the file is located and if flat file mode is
active. "

Hmm, that might be related to one of the other changes that
were in 1.3.18. Couldn't test it myself at the moment... I
wasn't really aware this was possible before... Jerzy?

[Henri Volk]

Logged In: YES
user_id=133439

>> WinCvs no longer has a global CVSROOT
>> preference so this is the place where it's actually needed.

Hmm, well, never needed to set it that way, since we
normally use the same repository. If I have more, I use
another location.

>> wasn't really aware this was possible before...

It's (was) a great feature! If you work on many projects and
you then want to check in...
Can I have it back please ;-)

Thanks
Henri

[Jerzy Kaczorowski]

Logged In: YES
user_id=119527

If it's all from the same repostory you should probably set the
"top level admin" on.

That "feature" can be very dangerous - if you (accidentally)
mix and match repositories the commit may go to the wrong
place!

For now, if you use one CVSROOT anyway (e.g. office
environment) You can still set the CVSROOT in the OS
environment to get it working for now.

We will fix that when the queuing of CVS commands will be
implemented so all commands run in their own directories.

[Colm O Flaherty]

Logged In: YES
user_id=884387

This may be a bigger issue, and seems to be still an issue
in 2.0.0.2 (apologies for the old version.. my
organisational standard for WinCVS is this version)..

It seems to be an issue for **any** command, when in flat
mode, where the current directory is not the directory
where the file (the target of the command) resides. The
actual command that is run is like so:

cvs -z3 -w update -p -r 1.3 --
exmanagement\Cash\rec_import.proc (in directory
C:\CVSSource\)

and this fails with the following error:

Empty password used - try 'cvs login' with a real password

Note that this happens regardless of whether you have
actually logged in or not.. so the error message is
actually quite misleading.

[Oliver Giesen]

Logged In: YES
user_id=158827

> It seems to be an issue for **any** command, when in flat
> mode, where the current directory is not the directory
> where the file (the target of the command) resides. The
> actual command that is run is like so:
>
> cvs -z3 -w update -p -r 1.3 --
> exmanagement\Cash\rec_import.proc (in directory
> C:\CVSSource\)

Well, I actually do that all the time and I never
experienced any problems. In my case however all directories
down to the one I'm located in are CVS-controlled. I could
imagine that it might behave differently when you are
running the command from a non-controlled folder, though. Is
your selected folder under CVS control when this happens?

> and this fails with the following error:
>
> Empty password used - try 'cvs login' with a real
> password

Does it really *fail* ? In my experience that message is
usually little more than a warning and tends to reappear
after client upgrades even after you have already run login.
Caching of empty passwords appears to be a bit quirky
sometimes. Nevertheless this has never stopped the command
from succeeding for me. That is of course given that the
password is indeed empty (as is often the case for anonymous
guest-type access).