Hi.

Recently I sent Eric (who is CC-ed and these days sporadic available
for deeper analyses) email titled as "git-svn cloning get stuck during
processing huge file".
It was about "git svn clone ..." against repository which had big
third-party files (1,3 GB, 1,1 GB, 80 MB, 55 MB ), temporary stored in
that repository by mistake (deleted in next revisions).
So, because I don' t want them, naturally, neither in WC, nor in
.git/object files as a part of history,
I used "--ignore-paths" to avoid them.

Until today I though that process git-svn hangs, because I did not see
any progress indicator for a  long time, more than couple of hours.
(Thankful to "--ignore-paths", there were no temporary file(s) under
./git which rapidly increase on second level, but still there were
files such as (MAC's git-svn):
-rw-------   1 vladimirdosen  staff     0 Feb 26 17:51
Git_git_blob_1101_0_gyOjAm
-rw-------   1 vladimirdosen  staff     0 Feb 26 17:51
Git_svn_delta_1101_0_kG6AtD
-rw-------   1 vladimirdosen  staff     0 Feb 26 17:51 Git_svn_hash_OkjgGH
, as well as
-rw-r--r--  1 vladimirdosen  staff     0 Feb 26 17:51 index.lock
under /.git/svn/refs/remotes/git-svn.
... and I could note that process "get stuck" somewhere between
Ra.gs_do_update's call for "$reporter->finish_report($pool);"
and
return from Fetcher.apply_textdelta. )

Fortunately, today, probably thankful to much better network
condition, I succeed with "latency" 60-80 minutes,
where handling of mentioned files has taken 98% of total cloning.

So now, my question(s) could be rephrased:
Is there any way that ignoring with "ignore-paths" can be complete
ignoring of marked files,
or why beside many "return undef if $self->is_path_ignored" in git-svn
this  cloning(fetching) takes significant time anyhow?

It is not only about waiting, but I was misled that process is not
possible at all if I want to migrate SVN with full history :)

Thanks,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to