cvs2svn 1.3.0 crash in pass8

Rick Altherr <raltherrapple.com> writes:
> Here's the output from trunk cvs2svn as of 10:31AM
PST:
> 
> ----- pass 2 -----
> Checking for blocked exclusions...
> Checking for forced tags with commits...
> Checking for tag/branch mismatches...
> Traceback (most recent call last):
>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
5291, in ?
>      main()
>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
5283, in main
>      convert(start_pass, end_pass)
>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
4903, in convert
>      _passes[i]()
>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
4312, in pass2
>      tags_db[tag] = None
>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
835, in
> __setitem__
>      self.db[key] = value
> TypeError: gdbm mappings have string elements only

Thanks.

Dang.  Well, if you can get this down to a minimal
reproduction case
(i.e., minimal in terms of data required to reproduce), that
would
help us a lot in fixing it.  

If your data is confidential, one strategy is to hand-munge
the RCS
files such that each branch/tag in the 'symbols' header is
replaced
with a meaningless unique ID, and all the file content (the
diff
hunks) are just empty.  It's the meta-structure that's
causing the
problem, most likely, not the versioned content.

Getting down to a minimal repro recipe makes this
data-cleaning
process much easier, of course.

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed
Development On Demand


> --
> Rick Altherr
> Architecture and Performance Group
> raltherrapple.com
> 
> 
> On Mar 14, 2006, at 7:26 AM, kfogelcollab.net wrote:
> 
> > Rick Altherr <raltherrapple.com> writes:
> >> It looks like it is trying to do a lookup into
the database with a
> >> key of None rather than a string.  I cannot
provide the repository,
> >> but I can run tests on it to help diagnose the
problem.
> >
> > Hmmm, that sounds like a bug in cvs2svn, yes.  But
does it reproduce
> > if you try with latest trunk cvs2svn (i.e., newer
than the 1.3.0
> > release)?
> >
> > -Karl
> >
> > -- 
> > www.collab.net  <>  CollabNet  | 
Distributed Development On Demand
> 
> 

-- 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org

I've narrowed it down to a one-file test case.  The
command-line I am  
using is:

cvs2svn --no-default-eol --dump-only
--force-branch=CHUD-4_1_0 -- 
force-branch=CHUD-4_0_1 --force-branch=apg
--force-branch=start Examples


Thanks,
--
Rick Altherr
Architecture and Performance Group
raltherrapple.com


On Mar 14, 2006, at 9:06 AM, kfogelcollab.net wrote:

> Rick Altherr <raltherrapple.com> writes:
>> Here's the output from trunk cvs2svn as of 10:31AM
PST:
>>
>> ----- pass 2 -----
>> Checking for blocked exclusions...
>> Checking for forced tags with commits...
>> Checking for tag/branch mismatches...
>> Traceback (most recent call last):
>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
5291, in ?
>>      main()
>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
5283, in main
>>      convert(start_pass, end_pass)
>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
4903, in  
>> convert
>>      _passes[i]()
>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
4312, in pass2
>>      tags_db[tag] = None
>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
835, in
>> __setitem__
>>      self.db[key] = value
>> TypeError: gdbm mappings have string elements only
>
> Thanks.
>
> Dang.  Well, if you can get this down to a minimal
reproduction case
> (i.e., minimal in terms of data required to reproduce),
that would
> help us a lot in fixing it.
>
> If your data is confidential, one strategy is to
hand-munge the RCS
> files such that each branch/tag in the 'symbols'
header is replaced
> with a meaningless unique ID, and all the file content
(the diff
> hunks) are just empty.  It's the meta-structure
that's causing the
> problem, most likely, not the versioned content.
>
> Getting down to a minimal repro recipe makes this
data-cleaning
> process much easier, of course.
>
> -Karl
>
> -- 
> www.collab.net  <>  CollabNet  |  Distributed
Development On Demand
>
>
>> --
>> Rick Altherr
>> Architecture and Performance Group
>> raltherrapple.com
>>
>>
>> On Mar 14, 2006, at 7:26 AM, kfogelcollab.net wrote:
>>
>>> Rick Altherr <raltherrapple.com> writes:
>>>> It looks like it is trying to do a lookup
into the database with a
>>>> key of None rather than a string.  I cannot
provide the repository,
>>>> but I can run tests on it to help diagnose
the problem.
>>>
>>> Hmmm, that sounds like a bug in cvs2svn, yes. 
But does it reproduce
>>> if you try with latest trunk cvs2svn (i.e.,
newer than the 1.3.0
>>> release)?
>>>
>>> -Karl
>>>
>>> -- 
>>> www.collab.net  <>  CollabNet  | 
Distributed Development On Demand
>>
>>
>
> -- 


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org

Any update on this.  I checked the list archives and it
seems to have  
been dead for a week.
--
Rick Altherr
Architecture and Performance Group
raltherrapple.com


On Mar 14, 2006, at 9:06 AM, kfogelcollab.net wrote:

> Rick Altherr <raltherrapple.com> writes:
>> Here's the output from trunk cvs2svn as of 10:31AM
PST:
>>
>> ----- pass 2 -----
>> Checking for blocked exclusions...
>> Checking for forced tags with commits...
>> Checking for tag/branch mismatches...
>> Traceback (most recent call last):
>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
5291, in ?
>>      main()
>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
5283, in main
>>      convert(start_pass, end_pass)
>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
4903, in  
>> convert
>>      _passes[i]()
>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
4312, in pass2
>>      tags_db[tag] = None
>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
835, in
>> __setitem__
>>      self.db[key] = value
>> TypeError: gdbm mappings have string elements only
>
> Thanks.
>
> Dang.  Well, if you can get this down to a minimal
reproduction case
> (i.e., minimal in terms of data required to reproduce),
that would
> help us a lot in fixing it.
>
> If your data is confidential, one strategy is to
hand-munge the RCS
> files such that each branch/tag in the 'symbols'
header is replaced
> with a meaningless unique ID, and all the file content
(the diff
> hunks) are just empty.  It's the meta-structure
that's causing the
> problem, most likely, not the versioned content.
>
> Getting down to a minimal repro recipe makes this
data-cleaning
> process much easier, of course.
>
> -Karl
>
> -- 
> www.collab.net  <>  CollabNet  |  Distributed
Development On Demand
>
>
>> --
>> Rick Altherr
>> Architecture and Performance Group
>> raltherrapple.com
>>
>>
>> On Mar 14, 2006, at 7:26 AM, kfogelcollab.net wrote:
>>
>>> Rick Altherr <raltherrapple.com> writes:
>>>> It looks like it is trying to do a lookup
into the database with a
>>>> key of None rather than a string.  I cannot
provide the repository,
>>>> but I can run tests on it to help diagnose
the problem.
>>>
>>> Hmmm, that sounds like a bug in cvs2svn, yes. 
But does it reproduce
>>> if you try with latest trunk cvs2svn (i.e.,
newer than the 1.3.0
>>> release)?
>>>
>>> -Karl
>>>
>>> -- 
>>> www.collab.net  <>  CollabNet  | 
Distributed Development On Demand
>>
>>
>
> -- 


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org

Rick Altherr <raltherrapple.com> writes:
> Any update on this.  I checked the list archives and it
seems to have
> been dead for a week.

My apologies, Rick.  It's been an unusual week and I
haven't been
responding to email as much as I normally do.  Worse, I'm
going on
vacation for at least a month soon, so will not be able to
follow up
much for a while.

I tried to reproduce this with head (r1803) of cvs2svn trunk
and could
not.  I filed issue 98 with all the details, see:

   h
ttp://cvs2svn.tigris.org/issues/show_bug.cgi?id=98

(Yes, I also tried with the cvs repos named
"EXAMPLES".)

Mike Pilato had a very plausible theory that the db-back-end
choice
could be the important variable here.  I don't have time to
investigate that further right now, but see the issue for a
place to
start.

Good luck,
-Karl

> On Mar 14, 2006, at 9:06 AM, kfogelcollab.net wrote:
>
>> Rick Altherr <raltherrapple.com> writes:
>>> Here's the output from trunk cvs2svn as of
10:31AM PST:
>>>
>>> ----- pass 2 -----
>>> Checking for blocked exclusions...
>>> Checking for forced tags with commits...
>>> Checking for tag/branch mismatches...
>>> Traceback (most recent call last):
>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
5291, in ?
>>>      main()
>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
5283, in main
>>>      convert(start_pass, end_pass)
>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
4903, in
>>> convert
>>>      _passes[i]()
>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
4312, in pass2
>>>      tags_db[tag] = None
>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
835, in
>>> __setitem__
>>>      self.db[key] = value
>>> TypeError: gdbm mappings have string elements
only
>>
>> Thanks.
>>
>> Dang.  Well, if you can get this down to a minimal
reproduction case
>> (i.e., minimal in terms of data required to
reproduce), that would
>> help us a lot in fixing it.
>>
>> If your data is confidential, one strategy is to
hand-munge the RCS
>> files such that each branch/tag in the 'symbols'
header is replaced
>> with a meaningless unique ID, and all the file
content (the diff
>> hunks) are just empty.  It's the meta-structure
that's causing the
>> problem, most likely, not the versioned content.
>>
>> Getting down to a minimal repro recipe makes this
data-cleaning
>> process much easier, of course.
>>
>> -Karl
>>
>> -- 
>> www.collab.net  <>  CollabNet  |  Distributed
Development On Demand
>>
>>
>>> --
>>> Rick Altherr
>>> Architecture and Performance Group
>>> raltherrapple.com
>>>
>>>
>>> On Mar 14, 2006, at 7:26 AM, kfogelcollab.net wrote:
>>>
>>>> Rick Altherr <raltherrapple.com> writes:
>>>>> It looks like it is trying to do a
lookup into the database with a
>>>>> key of None rather than a string.  I
cannot provide the repository,
>>>>> but I can run tests on it to help
diagnose the problem.
>>>>
>>>> Hmmm, that sounds like a bug in cvs2svn,
yes.  But does it reproduce
>>>> if you try with latest trunk cvs2svn (i.e.,
newer than the 1.3.0
>>>> release)?
>>>>
>>>> -Karl
>>>>
>>>> -- 
>>>> www.collab.net  <>  CollabNet  | 
Distributed Development On Demand
>>>
>>>
>>
>> -- 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org

And then I spoke too soon.  Just after I sent that, it died
in pass 8  
with:

Starting Subversion r2521 / 11576
Traceback (most recent call last):
   File
"/Users/kc8apf/Desktop/cvs2svn-trunk/cvs2svn",
line 5291, in ?
     main()
   File
"/Users/kc8apf/Desktop/cvs2svn-trunk/cvs2svn",
line 5283, in  
main
     convert(start_pass, end_pass)
   File
"/Users/kc8apf/Desktop/cvs2svn-trunk/cvs2svn",
line 4903, in  
convert
     _passes[i]()
   File
"/Users/kc8apf/Desktop/cvs2svn-trunk/cvs2svn",
line 4611, in  
pass8
     repos.commit(svn_commit)
   File
"/Users/kc8apf/Desktop/cvs2svn-trunk/cvs2svn",
line 3577, in  
commit
     self._fill_symbolic_name(svn_commit)
   File
"/Users/kc8apf/Desktop/cvs2svn-trunk/cvs2svn",
line 3416, in  
_fill_symbolic_name
     self._fill(symbol_fill, dest_prefix, dest_key, sources)
   File
"/Users/kc8apf/Desktop/cvs2svn-trunk/cvs2svn",
line 3541, in  
_fill
     copy_source.prefix, sources[0].revnum, prune_ok)
   File
"/Users/kc8apf/Desktop/cvs2svn-trunk/cvs2svn",
line 3541, in  
_fill
     copy_source.prefix, sources[0].revnum, prune_ok)
   File
"/Users/kc8apf/Desktop/cvs2svn-trunk/cvs2svn",
line 3504, in  
_fill
     copy_source.revnum)
   File
"/Users/kc8apf/Desktop/cvs2svn-trunk/cvs2svn",
line 3377, in  
_copy_path
     src_contents = self._get_node(src_key)
   File
"/Users/kc8apf/Desktop/cvs2svn-trunk/cvs2svn",
line 3228, in  
_get_node
     return self.nodes_db[key]
   File
"/Users/kc8apf/Desktop/cvs2svn-trunk/cvs2svn",
line 842, in  
__getitem__
     return marshal.loads(self.db[key])
   File
"/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/ 
python2.3/site-packages/bsddb3/__init__.py", line 213,
in __getitem__
     return self.db[key]
KeyError

I'll see if I can cut this down to a reasonable test case. 
The  
command-line I am using is:
cvs2svn --dump-only --no-default-eol
--force-branch=CHUD-4_1_0 -- 
force-branch=apg --force-branch=start
--force-branch=CHUD-4_0_1  
(repository)
--
Rick Altherr
Architecture and Performance Group
raltherrapple.com


On Mar 27, 2006, at 3:24 PM, kfogel wrote:

> Rick Altherr <raltherrapple.com> writes:
>> Any update on this.  I checked the list archives
and it seems to have
>> been dead for a week.
>
> My apologies, Rick.  It's been an unusual week and I
haven't been
> responding to email as much as I normally do.  Worse,
I'm going on
> vacation for at least a month soon, so will not be able
to follow up
> much for a while.
>
> I tried to reproduce this with head (r1803) of cvs2svn
trunk and could
> not.  I filed issue 98 with all the details, see:
>
>    h
ttp://cvs2svn.tigris.org/issues/show_bug.cgi?id=98
>
> (Yes, I also tried with the cvs repos named
"EXAMPLES".)
>
> Mike Pilato had a very plausible theory that the
db-back-end choice
> could be the important variable here.  I don't have
time to
> investigate that further right now, but see the issue
for a place to
> start.
>
> Good luck,
> -Karl
>
>> On Mar 14, 2006, at 9:06 AM, kfogelcollab.net wrote:
>>
>>> Rick Altherr <raltherrapple.com> writes:
>>>> Here's the output from trunk cvs2svn as of
10:31AM PST:
>>>>
>>>> ----- pass 2 -----
>>>> Checking for blocked exclusions...
>>>> Checking for forced tags with commits...
>>>> Checking for tag/branch mismatches...
>>>> Traceback (most recent call last):
>>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
5291, in ?
>>>>      main()
>>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
5283, in main
>>>>      convert(start_pass, end_pass)
>>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
4903, in
>>>> convert
>>>>      _passes[i]()
>>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
4312, in  
>>>> pass2
>>>>      tags_db[tag] = None
>>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
835, in
>>>> __setitem__
>>>>      self.db[key] = value
>>>> TypeError: gdbm mappings have string
elements only
>>>
>>> Thanks.
>>>
>>> Dang.  Well, if you can get this down to a
minimal reproduction case
>>> (i.e., minimal in terms of data required to
reproduce), that would
>>> help us a lot in fixing it.
>>>
>>> If your data is confidential, one strategy is
to hand-munge the RCS
>>> files such that each branch/tag in the
'symbols' header is replaced
>>> with a meaningless unique ID, and all the file
content (the diff
>>> hunks) are just empty.  It's the
meta-structure that's causing the
>>> problem, most likely, not the versioned
content.
>>>
>>> Getting down to a minimal repro recipe makes
this data-cleaning
>>> process much easier, of course.
>>>
>>> -Karl
>>>
>>> -- 
>>> www.collab.net  <>  CollabNet  | 
Distributed Development On Demand
>>>
>>>
>>>> --
>>>> Rick Altherr
>>>> Architecture and Performance Group
>>>> raltherrapple.com
>>>>
>>>>
>>>> On Mar 14, 2006, at 7:26 AM, kfogelcollab.net wrote:
>>>>
>>>>> Rick Altherr <raltherrapple.com> writes:
>>>>>> It looks like it is trying to do a
lookup into the database  
>>>>>> with a
>>>>>> key of None rather than a string. 
I cannot provide the  
>>>>>> repository,
>>>>>> but I can run tests on it to help
diagnose the problem.
>>>>>
>>>>> Hmmm, that sounds like a bug in
cvs2svn, yes.  But does it  
>>>>> reproduce
>>>>> if you try with latest trunk cvs2svn
(i.e., newer than the 1.3.0
>>>>> release)?
>>>>>
>>>>> -Karl
>>>>>
>>>>> -- 
>>>>> www.collab.net  <>  CollabNet  | 
Distributed Development On  
>>>>> Demand
>>>>
>>>>
>>>
>>> -- 


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org

Well, I did some poking around in my setup today and
realized I  
didn't have berkely db installed.  It appears that cvs2svn
falls back  
to gdbm if it can't find bsddb.  That's what was
happening.  I  
installed berkeley db and made sure bsddb was installed and
now  
things appear to be going smoothly.
--
Rick Altherr
Architecture and Performance Group
raltherrapple.com


On Mar 27, 2006, at 3:24 PM, kfogel wrote:

> Rick Altherr <raltherrapple.com> writes:
>> Any update on this.  I checked the list archives
and it seems to have
>> been dead for a week.
>
> My apologies, Rick.  It's been an unusual week and I
haven't been
> responding to email as much as I normally do.  Worse,
I'm going on
> vacation for at least a month soon, so will not be able
to follow up
> much for a while.
>
> I tried to reproduce this with head (r1803) of cvs2svn
trunk and could
> not.  I filed issue 98 with all the details, see:
>
>    h
ttp://cvs2svn.tigris.org/issues/show_bug.cgi?id=98
>
> (Yes, I also tried with the cvs repos named
"EXAMPLES".)
>
> Mike Pilato had a very plausible theory that the
db-back-end choice
> could be the important variable here.  I don't have
time to
> investigate that further right now, but see the issue
for a place to
> start.
>
> Good luck,
> -Karl
>
>> On Mar 14, 2006, at 9:06 AM, kfogelcollab.net wrote:
>>
>>> Rick Altherr <raltherrapple.com> writes:
>>>> Here's the output from trunk cvs2svn as of
10:31AM PST:
>>>>
>>>> ----- pass 2 -----
>>>> Checking for blocked exclusions...
>>>> Checking for forced tags with commits...
>>>> Checking for tag/branch mismatches...
>>>> Traceback (most recent call last):
>>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
5291, in ?
>>>>      main()
>>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
5283, in main
>>>>      convert(start_pass, end_pass)
>>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
4903, in
>>>> convert
>>>>      _passes[i]()
>>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
4312, in  
>>>> pass2
>>>>      tags_db[tag] = None
>>>>    File
"/Users/kc8apf/Desktop/cvs2svn/cvs2svn", line
835, in
>>>> __setitem__
>>>>      self.db[key] = value
>>>> TypeError: gdbm mappings have string
elements only
>>>
>>> Thanks.
>>>
>>> Dang.  Well, if you can get this down to a
minimal reproduction case
>>> (i.e., minimal in terms of data required to
reproduce), that would
>>> help us a lot in fixing it.
>>>
>>> If your data is confidential, one strategy is
to hand-munge the RCS
>>> files such that each branch/tag in the
'symbols' header is replaced
>>> with a meaningless unique ID, and all the file
content (the diff
>>> hunks) are just empty.  It's the
meta-structure that's causing the
>>> problem, most likely, not the versioned
content.
>>>
>>> Getting down to a minimal repro recipe makes
this data-cleaning
>>> process much easier, of course.
>>>
>>> -Karl
>>>
>>> -- 
>>> www.collab.net  <>  CollabNet  | 
Distributed Development On Demand
>>>
>>>
>>>> --
>>>> Rick Altherr
>>>> Architecture and Performance Group
>>>> raltherrapple.com
>>>>
>>>>
>>>> On Mar 14, 2006, at 7:26 AM, kfogelcollab.net wrote:
>>>>
>>>>> Rick Altherr <raltherrapple.com> writes:
>>>>>> It looks like it is trying to do a
lookup into the database  
>>>>>> with a
>>>>>> key of None rather than a string. 
I cannot provide the  
>>>>>> repository,
>>>>>> but I can run tests on it to help
diagnose the problem.
>>>>>
>>>>> Hmmm, that sounds like a bug in
cvs2svn, yes.  But does it  
>>>>> reproduce
>>>>> if you try with latest trunk cvs2svn
(i.e., newer than the 1.3.0
>>>>> release)?
>>>>>
>>>>> -Karl
>>>>>
>>>>> -- 
>>>>> www.collab.net  <>  CollabNet  | 
Distributed Development On  
>>>>> Demand
>>>>
>>>>
>>>
>>> -- 


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org

Rick Altherr wrote:
> Well, I did some poking around in my setup today and
realized I  didn't
> have berkely db installed.  It appears that cvs2svn
falls back  to gdbm
> if it can't find bsddb.  That's what was happening. 
I  installed
> berkeley db and made sure bsddb was installed and now 
things appear to
> be going smoothly.

Last night, I tried the reproduction with and without the
python-bsddb3
module.  It succeeded both times.

-- 
C. Michael Pilato <cmpilatocollab.net>
CollabNet   <>   www.collab.net   <>  
Distributed Development On Demand

I've narrowed it down to a single module that I can send. 
I noticed  
that this is one of the folders that contains a file with a
funny  
filename.  Specifically, there is a file name Icon^M.  This
is  
correct and the filename does need to contain a control
character.   
CVS seems to handle this.

Let me know to whom and where to send the tarball of the
module.
--
Rick Altherr
Architecture and Performance Group
raltherrapple.com


On Mar 28, 2006, at 2:20 PM, C. Michael Pilato wrote:

> Rick Altherr wrote:
>> Well, I did some poking around in my setup today
and realized I   
>> didn't
>> have berkely db installed.  It appears that cvs2svn
falls back  to  
>> gdbm
>> if it can't find bsddb.  That's what was
happening.  I  installed
>> berkeley db and made sure bsddb was installed and
now  things  
>> appear to
>> be going smoothly.
>
> Last night, I tried the reproduction with and without
the python- 
> bsddb3
> module.  It succeeded both times.
>
> -- 
> C. Michael Pilato <cmpilatocollab.net>
> CollabNet   <>   www.collab.net   <>  
Distributed Development On  
> Demand


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org

Rick Altherr wrote:
> I've narrowed it down to a single module that I can
send.  I noticed 
> that this is one of the folders that contains a file
with a funny 
> filename.  Specifically, there is a file name Icon^M. 
This is  correct
> and the filename does need to contain a control
character.   CVS seems
> to handle this.

A perverse  filename
like that can easily be expected to cause
problems in the conversion.  For example, the
cvs2svn-data.revs file and
its friends are probably not robust against such filenames. 
They would
probably have to be made null-terminated, or the filenames
output with
"repr" instead of "str", or (my
preference) rethought entirely.

Michael

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org

Michael Haggerty wrote:
> Rick Altherr wrote:
>>I've narrowed it down to a single module that I can
send.  I noticed 
>>that this is one of the folders that contains a file
with a funny 
>>filename.  Specifically, there is a file name
Icon^M.  This is  correct
>>and the filename does need to contain a control
character.   CVS seems
>>to handle this.
> 
> A perverse  filename
like that can easily be expected to cause
> problems in the conversion.  For example, the
cvs2svn-data.revs file and
> its friends are probably not robust against such
filenames.  They would
> probably have to be made null-terminated, or the
filenames output with
> "repr" instead of "str", or (my
preference) rethought entirely.

I looked into this problem some more and found out (to my
surprise!)
that Subversion itself cannot handle filenames containing
control
characters.  The concept of control character is defined in
ctype.c,
namely any character with ASCII code in the range 0-31
(inclusive) or 127.

Unfortunately I only discovered this *after* locally
implementing
null-terminated data handling in the cvs2svn-data files :-(

So I think you will have to give up your perverse filename
if you want
to use Subversion, or else check it in with a different name
and rename
it manually each time after you check it out.  (To make the
conversion
go through with an alternative filename, you should make a
copy of your
CVS repository, and in the copy rename the 'Icon^M,v' file
to something
allowed.)

As far as cvs2svn goes, I think we should explicitly check
for illegal
filenames while doing the conversion, and give the user a
better error
message if a problem is found.

Michael

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org