Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
tmh at nodomain.org (Tony Hoyle) writes:
> On 09 Apr 2003 17:14:20 +0200, Oliver Koltermann <okoltermann at gmx.de> wrote:
>
> >Hello NG,
> >
> >when issuing the command
> >
> >cvs checkout -d "here" ampersandmodule
> >
> >on cvsnt 2.0.0 client and server the output is completly displaced. It
> >looks something like the following:
>
> Mixing -d with an ampersand module sounds pretty unique. To support it it
> looks like I'll have to do quite a lot of rewriting (no idea why it's
> documented as working as there's clearly no support for it in the code..).
Hello again,
it seems to me that nobody else in here uses ampersand modules?! As I
described in this thread the new CVSNT 2.0.x runs into trouble when
processing a "checkout -d xyz ampermod" command. The path structure
gets completely corrupted.
But now I saw an even more bad behaviour: While using the workaround
cvs checkout ampermod
ren ampermod xyz
i even get a corrupted working copy *without* the -d option. There
seems to be a discrepancy on the place between some files and the
corresponding CVS folder. I get a CVS folder in the actual working
directory with the Entries, Enties.Extra, Repository and Root of a
subdir (WinCVS claims missing files here). In the corresponding
subdirectory I find the files and a CVS folder with contents that lead
WinCVS to the conclusion that the files are "NonCvs file"s.
When inspecting the files the set in the root folder looks right for
me while the ones in the folder look like this:
Entries 0KB
Entries.Extra 0KB
Entries.Extra.Log One "A /xyz.txt///" line per file
Entries.Log One "A /xyz.txt/1.3/Thu Mar 20 13:15:48 2003//
/xyz.txt/1.3/Thu Mar 20 13:15:48 2003//"
block per file
Repository and Root look alright.
The next update brings the files in a state more "readable" by
WinCVS. So the "NonCVS file"s seem to be a WinCVS issue (not parsing
the .Log files?) i guess. But the CVS dir in the working directory
stays there.
Sorry for the bad explanation. Please ask if something is unclear.
Thanks for any help,
OK.
PS: This is 2.0.0 Server and 2.0.1 Client. Please tell me if this has
something to do with the TopLevelAdmin issue fixed in
2.0.1. Maybe I just have to update the server too?