RE: Re: Some Macros topic.

> It seems only (1-1) was appropreate for this list...
> I had exposed newbie-wise... :-(

No need to apologize. It's always good to discuss some things first. And 
IMO discussion's easier on the list than on the tracker.


> # (1-2): Because I didn't understand `virtual module' well.

Note that this is not an "official" term. AFAIK there is no distinct 
term for these (i.e. modules that have no direct physical representation 
in the repository but are only defined by the modules file). The CVS 
world is unfortunately missing distinct terms for a lot of things and 
also often reuses some in an ambiguous manner (e.g. CVSROOT).


> > Hmm, it'd be news to me that you could give a relative module 
> path. Relative
> > to what would that be?
> 
> getcwd.

On the client? That doesn't make sense AFAICT as the module name passed 
to RLog refers to the server's view of things, not the client's. The 
only possible situation where I could imagine that this would produce 
anything useful is when invoked from a CVS-controlled directory. In that 
case ".." would probably attempt to read the repository path from 
./CVS/Repository and then try to go one level up from there. I'll try to 
do a few tests in my lunch break today.

 
> > > (4)I want `flexibility cvs add' Macro like RecursiveAddTk.py but 
> no-
> > > recurse.
> > >    # I actually need `cvs add -ko'.
> > 
> > That's one for the issue tracker. What we really need is a full-
> fledged Add
> 
> I think I'll regist to the tracker. (I can't find the same issue.
> Please tell me if there is already that.)
> By the way, this feature should be supported by which macros or
> WinCvs itself, you think?

I think this one should be implemented in the core to replace the 
current Add functionality.

 
> > >   * I think at least we should not load any DLL if the settings
> > >     (WinCvs -> TCL DLL) is wrong.
> > 
> > Most of the time it works best if the settings are just kept 
> blank. However,
> 
> I'm thinking `blank' and `wrong' separately.

Ah, I see. However, intentionally specifying a wrong path would only be 
a workaround to disable the loading of DLLs, wouldn't it? I don't think 
we should drive people into workarounds. We should supply real 
solutions.


> For example, if the preference is `tcl90.dll'(of cource it isn't
> on your system), WinCvs will try to load tcl84.dll after all. 

I wasn't aware that it did this. I never tried unloading TCL so far (I'm 
not even sure it's possible if you've got Python installed as some of 
the Python macros intrinsically load TCL themselves). It defintitely 
should not go through the whole scanning algorithm if there is an 
explicit user setting in place IMO.


> > >   * It would be nice if WinCvs had the setting for process local
> > >     PATH environment variable.
> > 
> > I think the above would take care of that, or did I maybe 
> misunderstand you?
> 
> If my broken English didn't confuse you, maybe you didn't 
> misunderstand me.
> 
> I thought if I could remove unnecessary path by the preference,
> but indeed we should take care, and it might be complex...

As I wrote above, scanning the PATH should not be done if there is an 
explicit user setting. If it currently does this it is a bug IMO.

Cheers,

Oliver
----	------------------
JID:	[email protected]
ICQ:	18777742	(http://wwp.icq.com/18777742)
 



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/NhFolB/TM
---------------------------------------------------------------------~->

 
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/