[Be-devel] .be/id-cache

[Matěj Cepl]

Hi,

I were doing rather large rebase on one of my repos, and I had still
endless problems with merge conflicts of .be/id-cache file. According to
http://thread.gmane.org/gmane.comp.bug-tracking.bugs-everywhere.devel/730 this
file is just a cache and could be regenrated. In order to avoid these
merge conflicts is either of these options possible?

1) put .be/id-cache into .gitignore (or .git/info/exclude)?
2) do something to BE, that it wouldn't generate the cache at all? I
would gladly sacrifice couple of miliseconds per be list for many
minutes of resolving crazy merge conflicts during git rebase. Is there
such configuration option?

Best,

Mat?j
--
http://www.ceplovi.cz/matej/, Jabber: mcepl at ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC

The state is the great fictitious entity by which everyone seeks
to live at the expense of everyone else.
-- Frederick Bastiat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: OpenPGP digital signature
URL: <http://void.printf.net/pipermail/be-devel/attachments/20130812/d848e06a/attachment.pgp>

[W. Trevor King]

Post by Matěj Cepl
1) put .be/id-cache into .gitignore (or .git/info/exclude)?

It's been in .gitignore since dfa742a (Add .be/id-cache to .gitignore,
2010-10-30).

Post by Matěj Cepl
2) do something to BE, that it wouldn't generate the cache at all? I
would gladly sacrifice couple of miliseconds per be list for many
minutes of resolving crazy merge conflicts during git rebase. Is there
such configuration option?

The cache maps from flat ID space to the nested
.be/<repo>/bugs/<bug>/comments/<comment> directory structure. I
expect removing the cache (and replacing it with a tree walk for every
ID lookup?) would add more than a few milliseconds to many commands.

Still, accessing out multi-file "database" is one of BE's bottlenecks.
Any work converting the current approach to a more scalable system is
welcome, but it's hard to hit both "efficient" and "mergeable".

Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://void.printf.net/pipermail/be-devel/attachments/20130812/d5ed56d1/attachment.pgp>