Menu
▾
▴
#335 Make CVSROOT parser smarter
It'd be nice if the CVSROOT parser used in the CVSROOT
"wizard" was able to resolve common CVSROOTs as well,
i.e. where username and hostname are not encoded as
keywords. Furthermore it should be able to recognize
keyword aliases (e.g. "ver" instead of "version",
"host" instead of "hostname", etc.).
Ideally it would also be able to retain the given
formatting (i.e. host/usename as non-keywords and
keyword aliases) in the produced CVSROOT string.
Logged In: YES
user_id=119527
I don't mind a smarter parser that can handle previous
CVSROOT entries or entries pasted from webpages instructions
but I don't like the idea of retaining such formatting.
I think of it as a migration, a "normalization" of CVSROOt entry
to a common and simple format. The path is always a part of
CVSROOT and so it deserves separate entry. So is the
protocol. But not all CVSROOTs contain username and other
components. It's better to have these as a keywords.
It would also make a code for formatting and the GUI much
more complex with no real gain. It's worth to work on the
parser side because it helps to handle CVSROOT from different
sources and helps with migration, but an effort to retain the
formatting is probably not worth it...
The aliases will be used at the later date. I want to make
CVSROOT string as short as possible so we will use the
shortest alias for that. And of course we ought to parse all
possible aliases.
Logged In: YES
user_id=158827
> It would also make a code for formatting and the GUI much
> more complex with no real gain. It's worth to work on the
> parser side because it helps to handle CVSROOT from different
> sources and helps with migration, but an effort to retain the
> formatting is probably not worth it...
Basically OK with me. My main argument in this would be that
encoding username and hostname as keywords immediately
renders the CVSROOT string incompatible to standard CVS
(most of the other keywords are only used rather seldomly I
think and most of them are on the CVSNT-only protocols
anyway). It is common practice to distribute source packages
with CVS metadata in place so users could immediately update
them without setup hassles. If this metadata cannot be read
by the receiving side because they're not using CVSNT or
even Windows this could fall back badly on the distributor.
> The aliases will be used at the later date. I want to make
> CVSROOT string as short as possible so we will use the
> shortest alias for that. And of course we ought to parse all
> possible aliases.
Wholeheartedly agreed.
Another idea in this context: I think the CVSROOT dialog UI
could be simplified a bit by scrapping the actual keywords
from the grid and only displaying their descriptions
instead, i.e. what's currently shown in the bottom panel
when you select a keyword. It should still be transparent
enough as the constructed CVSROOT is displayed anyway.
Logged In: YES
user_id=119527
Backwards-compatibility with regular CVS is a non-issue. One
should never operate the same sandbox with different CVS
clients. Also it seems like there is a CVSNT wrapper for that.
CVS metadata should not be present in the source code
distribution. One should use export command to create
distribution packages.
I was thinking about using descriptions in the list but it seems
like some of these are very long and I would rather leave some
space for the keyword's values...
Logged In: YES
user_id=158827
"CVS metadata should not be present in the source code
distribution. One should use export command to create
distribution packages."
That is IMO debatable. As I indicated before, I know quite a
few projects where this is done deliberately (using
anonymous read-only login data of course). It simply gives
users a quick-start way of being able to pull the latest
sources without having to bother too much with CVS setup.
Logged In: YES
user_id=119527
I would not like that to drift off topic...
I am just saying that it's not correct to distribute CVS
metadata in your source distribution, for various reasons
(which I offer to explain fully in an appropriate forum). Just
because some projects are doing so doesn't make it correct in
any way.
Standing on that grounds - we need not to be concerned with
a questionable distribution practices ;)