Generates file ids that are too long

Fixed in r333.

As discussed on IRC, please re-open this. Only directory names are checksummed still, so long basename(file) can still cause breakage.

Test case (not that I think you need one):

svn add VERY_LONG_FILE_NAME_THAT_BREAKS_THINGS_WHEN_GENERATING_REVIDS_LALALALALALALALALALALALALALALA
svn commit -m "add stupid file name"

bzr svn-import myrepo test-bzr
bzr: ERROR: Transport error: [Errno 36] File name too long: '/tmp/test-bzr/.bzr/repository/knits/db/svn-v2%3a2@a7d2e3ea-9551-48af-9aa1-510cb462931b--%56%45%52%59_%4c%4f%4e%47_%46%49%4c%45_%4e%41%4d%45_%54%48%41%54_%42%52%45%41%4b%53_%54%48%49%4e%47%53_%57%48%45%4e_%47%45%4e%45%52%41%54%49%4e%47_%52%45%56%49%44%53_%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41.knit' [Errno 36] File name too long: '/tmp/test-bzr/.bzr/repository/knits/db/svn-v2%3a2@a7d2e3ea-9551-48af-9aa1-510cb462931b--%56%45%52%59_%4c%4f%4e%47_%46%49%4c%45_%4e%41%4d%45_%54%48%41%54_%42%52%45%41%4b%53_%54%48%49%4e%47%53_%57%48%45%4e_%47%45%4e%45%52%41%54%49%4e%47_%52%45%56%49%44%53_%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41%4c%41.knit'

  status confirmed
  affects /bzr

Bazaar needs to have a consistent policy as to what length file ids are
allowed or should at least throw a decent exception if a file id is
being added that is too long to be stored by the current revision store.

What characters are being escaped, how and what the maximum length of a
file id therefore is is not something upper layers should have knowledge
of.

Robert hacked up a repository some time ago that allowed infinite (well,
somewhat) revision ids by using the checksum of a file id as filename.
Maybe this could be incorporated into the main tree sometime?
--
Jelmer Vernooij <email address hidden> - http://samba.org/~jelmer/

On 13 Jan 2007, Jelmer Vernooij <email address hidden> wrote:
> status confirmed
> affects /bzr
>
> Bazaar needs to have a consistent policy as to what length file ids are
> allowed or should at least throw a decent exception if a file id is
> being added that is too long to be stored by the current revision store.

I agree.

> What characters are being escaped, how and what the maximum length of a
> file id therefore is is not something upper layers should have knowledge
> of.
>
> Robert hacked up a repository some time ago that allowed infinite (well,
> somewhat) revision ids by using the checksum of a file id as filename.
> Maybe this could be incorporated into the main tree sometime?

At minimum, the next format should not allow errors to result from
passing in overly-long or otherwise hostile ids. I'm ok with doing a
change that does only that, but it is not a priority for me at the
moment -- I would rather format changes also work on efficiency.

--
Martin

  status fixcommitted

Fixed in the experimental ver3 branch.
--
Jelmer Vernooij <email address hidden> - http://samba.org/~jelmer/

On Sat, 2007-01-13 at 23:20 +0100, Jelmer Vernooij wrote:
> status confirmed
> affects /bzr
>
> Bazaar needs to have a consistent policy as to what length file ids are
> allowed or should at least throw a decent exception if a file id is
> being added that is too long to be stored by the current revision store.
>
> What characters are being escaped, how and what the maximum length of a
> file id therefore is is not something upper layers should have knowledge
> of.
>
> Robert hacked up a repository some time ago that allowed infinite (well,
> somewhat) revision ids by using the checksum of a file id as filename.
> Maybe this could be incorporated into the main tree sometime?

You use revision id and file id interchangeably here but they aren't.
bzr's current repository is already able to store 'infinite' length
*revision ids*, but not *file ids*.

So my repo format allows indefinite length file ids ;). It needs a
little cleanup to be mergable, mainly in handling of collisions.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

You say that the fix is commited in the ver3 branch.
However, this doesn't really help, since the ver3 branch isn't accessible for some reason.

rune@rune-prg:~/src/bzr.dev$ ./bzr branch https://open-ms.svn.sourceforge.net/svnroot/open-ms ~/src/open-ms
version of bzr-svn is experimental; output may change between revisions
bzr: ERROR: Transport error: [Errno 36] File name too long: u'/home/rune/src/open-ms/.bzr/repository/knits/45/1@6adb6e08-d915-0410-941f-83917bcadc18%3a%3a%4fpen%4d%53%252%46source%252%46%41%50%50%4c%49%43%41%54%49%4f%4e%53%252%46%53%50%45%43%56%49%45%57_%53%50%45%43%41%4e%4e%4f%54%41%54%45%252%46%53%50%45%43%41%4e%4e%4f%54%41%54%45%252%46config_specannotate.h.kndx' [Errno 36] File name too long: u'/home/rune/src/open-ms/.bzr/repository/knits/45/1@6adb6e08-d915-0410-941f-83917bcadc18%3a%3a%4fpen%4d%53%252%46source%252%46%41%50%50%4c%49%43%41%54%49%4f%4e%53%252%46%53%50%45%43%56%49%45%57_%53%50%45%43%41%4e%4e%4f%54%41%54%45%252%46%53%50%45%43%41%4e%4e%4f%54%41%54%45%252%46config_specannotate.h.kndx'

It's fixed in the 0.4 branch, already packaged for ubuntu.

I just pulled the newest 0.4 from http://people.samba.org/bzr/jelmer/bzr-svn/0.4/
It still gives the above error.

Can you branch the above repository?

Hmm, no - that fails here as well. Fixing this properly would either be very complex or would potentially break some existing users of bzr-svn.

Since this is no longer a problem with newer bzr formats, I would rather just keep things as is and simply advise you to use a newer format.

To use a newer format, use:

$ bzr init-repo --knitpack-subtree open-ms

$ cd open-ms

$ bzr branch https://open-ms.svn.sourceforge.net/svnroot/open-ms trunk

Thanks

But that unfortunately also fails (with ver. 0.92.0 and ver. 0.4 bzr-svn (from when I wrote my previous comment). I'm opening a new bug for that.

Because of the failure I pulled a new version of bzr-svn, which now requires >0.92.0 (shouldn't a stable version plugin stick to requiring stable versions of the mother program?).
So I tried it with the bzr trunk (from a few days ago). It failed. So I pulled a new version of that too.
Now I've come to the point of this little text: In the version of bzr I just pulled it does not recognize the --knitpack-subtree option you mention.

bzr.dev/bzr init-repo --knitpack-subtree open-ms-test3
bzr: ERROR: no such option: --knitpack-subtree

Do you have a suggestion about what option to use instead?

Apparently --knitpack has been renamed to --pack-0.92 so the commands above should be (with the newest development version of bzr anyway):

$ bzr init-repo --pack-0.92-subtree open-ms

$ cd open-ms

$ bzr branch https://open-ms.svn.sourceforge.net/svnroot/open-ms trunk

On Mon, 2007-11-26 at 13:57 +0000, Olberd wrote:
> But that unfortunately also fails (with ver. 0.92.0 and ver. 0.4 bzr-svn
> (from when I wrote my previous comment). I'm opening a new bug for that.
>
> Because of the failure I pulled a new version of bzr-svn, which now requires >0.92.0 (shouldn't a stable version plugin stick to requiring stable versions of the mother program?).
Released versions of bzr-svn always work with a released version of bzr.
Development versions of bzr-svn are always developed against a
development version of bzr. This is done so it's always possible to use
the latest and greatest improvements in bzr itself, often prerequisites
for implementing particular features in bzr-svn.

> So I tried it with the bzr trunk (from a few days ago). It failed. So I pulled a new version of that too.
> Now I've come to the point of this little text: In the version of bzr I just pulled it does not recognize the --knitpack-subtree option you mention.
>
> bzr.dev/bzr init-repo --knitpack-subtree open-ms-test3
> bzr: ERROR: no such option: --knitpack-subtree
This can't be bzr 0.92 or bzr.dev; both support --knitpack-subtree. What does 'bzr revno' in your bzr.dev directory print? It should be somewhere around 3020 if it's up to date.

Cheers,

Jelmer
--
Jelmer Vernooij <email address hidden> - http://samba.org/~jelmer/

On Mon, 2007-11-26 at 14:08 +0000, Olberd wrote:
> Apparently --knitpack has been renamed to --pack-0.92 so the commands
> above should be (with the newest development version of bzr anyway):
>
> $ bzr init-repo --pack-0.92-subtree open-ms
>
> $ cd open-ms
>
> $ bzr branch https://open-ms.svn.sourceforge.net/svnroot/open-ms trunk

Ah, that explains it. Sorry, I hadn't seen that yet. Does it work better
with those commands ?

--
Jelmer Vernooij <email address hidden> - http://samba.org/~jelmer/

No, unfortunately.

Used this bzr rev. from http://bazaar-vcs.org/bzr/bzr.dev/
rune@rune-prg:~/src/bzr.dev$ bzr revno
3025

Apparently it's not a consistent bug.
Managed to branch it in second try (using the above commands).