[squid-dev] Empty directories during bzr-to-git conversion

Amos Jeffries squid3 at treenet.co.nz
Thu Jun 1 13:04:29 UTC 2017


On 02/06/17 00:31, Eduard Bagdasaryan wrote:
> Hello,
>
> Working on upcoming bzr-to-git migration we noticed empty directories
> presence in bzr history. Therefore, since git does not care about
> directories (and creates them only for existing files), this conversion
> does not exactly preserve bzr history and may theoretically cause
> problems (e.g., build problems) for the affected revisions.
> Fortunately, there were probably few such cases in the whole history
> and all of them are old. Our analysis for Squid trunk showed the last
> such revision is 9440 dated 2009-01-18, containing empty
> 'errors/Japanese' folder. Here is the generated list for trunk:
>
> errors/Japanese, r9401-9440
> errors/Czech, r9436-9438
> lib/cppunit-1.10.0/contrib, r6693-8121
> lib/cppunit-1.10.0/include/msvc6, r6693-8121
> lib/cppunit-1.10.0/src/msvc6, r6693-8121
> helpers/external_acl, r5495-5516
> helpers, r5482-5494
> helpers/external_acl, r5482-5494
> helpers, r4765-5481
>
> There are 2 possible ways to address this problem:
>
> 1. Leave as is.
> 2. During conversion, add dummy files to the history when the empty
>    directory is created and remove those dummy files when the empty
>    directory is either removed or becomes non-empty. This requires extra
>    development cycles.

For the record there is also:

3. add one of those notes being used for other bzr-specific things to 
the relevant git commit.


>
> Note that both the missing (empty) directories and extra dummy files may
> break builds for the related revisions.
>

These all being code directories their removal should not break any 
builds, since build recursion into them needs a Makefile(.am) presence. 
IIRC they should all have been deleted in bzr at the point the last file 
was removed, the difference was an oversight.

> If nobody is against, to minimize development overhead,
> we are going to follow (1) in the above plan.
>

+1 on that.

Amos



More information about the squid-dev mailing list