Re: [PATCH 1.2/2 (fixed)] git-svn: fix output reporting from the delta fetcher

Pazu [off-list ref] writes:

Notice that there's no "CamelEar" directory. For some reason, it
wasn't fetched in the initial revision. Now, just to make sure this
isn't svn fault:

mini:~/devel/camel-git pazu$ svn ls -r11143
https://tech.bga.bunge.com/BungeHomeExt/GLS/trunk/java/bg-cam
.cvsignore
BungeIntegrationEar/
BungeIntegrationService/
BungeIntegrationServiceClient/
CamelEar/

Is CamelEar an empty directory (or was it an empty directory in the
first fetch) by any chance?

I think that presently git-svn does not create empty dirs when pulling
from svn.  It would be nice to have such directories created since
some projects will expect the empty dir to be there (no need to track
it in git, IMO).

On 11/28/06, Eric Wong [off-list ref] wrote:

Git itself cannot easily track empty directories (at least as far as
update-index and checkout) goes.
[...]
Is that something the git community wants?

No, I guess not. I detailed the real problem in my previous message,
and it had nothing to do with empty directories, but with git-svn
recording broken revisions from svn. Did you get it, or Trogdor ate my
email?

On 11/28/06, Seth Falcon [off-list ref] wrote:

Is CamelEar an empty directory (or was it an empty directory in the
first fetch) by any chance?

No, neither. The directory isn't empty on the requested revision, nor
in the initial revision. Anyways…

I've tried to init and fetch the repository again, and guess what, it
worked. So my bet that this was caused by a broken connection during
the initial fetch was probably right -- I'll try to "force" a broken
connection and see what happens…

Hmmm.…

mini:/tmp pazu$ git-svn init
https://tech.bga.bunge.com/BungeHomeExt/GLS/trunk/java/bg-cam
mini:/tmp pazu$ git-svn fetch
        A       bg-cam.ipr
        A       CamelWeb/CamelWeb.iml
        A       CamelWeb/.classpath
        A       CamelWeb/JavaSource/.emptyDir
        A       CamelWeb/.serverPreference
        A       CamelWeb/.website-config
        ...
        <<Here I turned AirPort off>>
Committing initial tree d14cd2aca9a6f15fdc8875212776c6a7cd111341
r8618 = 5a994a730da8dc8141fd116100a773061b7d4212
Creating fetcher for revision 5a994a730da8dc8141fd116100a773061b7d4212
Starting update on revision 9236
Opening CamelService/ejbModule/com/bunge/logistics/elevator/service/util/ElevatorConstants.java@8618
Error from SVN, (200003): Incomplete data: Delta source ended unexpectedly

When I deactivated AirPort, git-svn hang for a long while, but it
finally timed out and just saved what it got so far as the initial
revision. Then when git-svn tried to fetch the next revision, it ended
up trying to open a file that wasn't checked out during the (broken)
initial fetch.

Well, it seems I've found the problem. Unfortunately I have no idea
how to fix that… I'll read some subversion books and source code to
figure that out.

Pazu [off-list ref] wrote:

On 11/28/06, Eric Wong [off-list ref] wrote:

quoted

Git itself cannot easily track empty directories (at least as far as
update-index and checkout) goes.
[...]
Is that something the git community wants?

No, I guess not. I detailed the real problem in my previous message,
and it had nothing to do with empty directories, but with git-svn
recording broken revisions from svn. Did you get it, or Trogdor ate my
email?

Oops, I didn't notice the part about git-svn continuing despite a failed
connection.  Thanks for poking me again.
I'll look into how/if abort_edit/close_edit is called and how to deal
with a failed network connection.

-- 

Seth Falcon [off-list ref] wrote:

Pazu [off-list ref] writes:

quoted

Notice that there's no "CamelEar" directory. For some reason, it
wasn't fetched in the initial revision. Now, just to make sure this
isn't svn fault:

mini:~/devel/camel-git pazu$ svn ls -r11143
https://tech.bga.bunge.com/BungeHomeExt/GLS/trunk/java/bg-cam
.cvsignore
BungeIntegrationEar/
BungeIntegrationService/
BungeIntegrationServiceClient/
CamelEar/

Is CamelEar an empty directory (or was it an empty directory in the
first fetch) by any chance?

I think that presently git-svn does not create empty dirs when pulling
from svn.  It would be nice to have such directories created since
some projects will expect the empty dir to be there (no need to track
it in git, IMO).

Git itself cannot easily track empty directories (at least as far as
update-index and checkout) goes.

What I *can* do is run mktree and to force the creation of tree objects
with a 4b825dc642cb6eb9a060e54bf8d69288fbee4904 (empty) sub tree and run
commit-tree on it, but checkout/checkout-index would still need to be
modified to support it.

Is that something the git community wants?

--