[user] git-svn and svn cp

I hope this is the correct mailing list. If not please point me in the right direction.

I played a little with git (1.5.3.4 / debian) and had the following observation: Doing a "svn cp" (for example for a tag) results in a large traffic when doing a "git-svn fetch" afterwards.

To verify I did: git-svn clone -s svn://www.ogersoft.at/ogerlit git-svn fetch svn cp svn://... svn://... (one file ca 3mb) svk checkout (a tcpflow output of about 3k - plaintext commands, I think a svn checkout would be the same) git-svn fetch (a tcpflow output of 700k - containing a textdelta of nearly 700k)

So the question remains: Does svn-git dont know about lightweight svn copies? or can svn-git not handle them correct by now? or did I something wrong?

thanks gerhard

gerhard.oettl.ml@ogersoft.at writes:

I guess the --tags=... and --branches=... options of git-svn can help.

[ disclaimer: I never used git-svn on a repository with branches and
  tags ]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

You are aware of what the "-s" option does?

David Kastrup <dak@gnu.org> writes:

Not in the details. Well, I believe the accurate question (to original poster) is: does your svn repository use the standard svn layout (tags/, branches/, trunk/)?

On Nov 19, 2007, at 1:56 PM, Matthieu Moy wrote:

I personally don't know and I went through the code to see that it's an (undocumented) alias for --stdlayout.

I think this is irrelevant to the question he asked.

Now I think that the fact that SVN does "lightweight" copies by recording that such modification was in fact an `svn cp' / `svn mv' isn't important for git-svn, because the data end up in the Git repository which handles copies and moves much much better than SVN does. But here the concerns raised by Gerhard seem to be more network-wise, in which case I don't know. I looked at the code, things seem to happen under the hood of Git::SVN::Fetcher but I don't see what can be optimized (the code isn't trivial). Most of the access are done through the underlying SVN Perl bindings, so if someone knows how to use them better, I think Eric will be eager to see the patches :)

Benoit Sigoure schrieb:

I hoped this and it was one of the motivations for looking at git  ;-)

But why is so much traffic necessary to transfer data that is already _complete_ present in the local git repository? Traffic that seams not to be necessary when using the "not so good" svn.

gerhard

gerhard.oettl.ml@ogersoft.at writes:

Is it? What is the right behavior when the file has been changed within the git repository (after all, we are rebasing and not tracking the svn archive)?

While I would probably prefer getting a copy from the changed file rather than the original one, the matter does not seem completely trivial in its implications.

It is not a git problem (git has good packing properties) but rather a git-svn issue. So don't blame git in general.

Benoit Sigoure <tsuna@lrde.epita.fr> writes:

Well, I'm far enough from being a git-svn expert, but I suppose git-svn will special-case the content of tags/ and branches/ directories, and consider copies there to be tags and branches. I don't know whether git-svn does it efficiently, though.

If you use "svn copy" with the meaning "create a tag" with a destination other than tags/ directory, then, git-svn can not guess it was actually a tag.

On Nov 19, 2007, at 2:49 PM, Matthieu Moy wrote:

No, git-svn only needs to know where to look for branches and tags so that it can replicate them on the Git side by creating remote branches. It has nothing to do with the fact that a tag or a branch happen to be a copy of something else (which isn't necessarily true, I can perfectly create a tag out of the blue which has its own unique content, same thing for branches).

The question of Gerhard was thus, why do we need to transfer "so much" data over the network when we should be able to guess that the data is already in the Git repo (because git-svn can figure out that something is a copy of something else -- because SVN records this information -- and thus save the network from downloading useless deltas). It's possible that the code can be optimized to handle this, or so I guess.

gerhard.oettl.ml@ogersoft.at wrote:

Older versions of the Perl SVN bindings have a broken do_switch() function, so I fall back to the do_update() function which re-downloads the whole tree instead..

SVN 1.4.4+ has this fix which allows do_switch() to be used instead of do_update().

do_switch() will only download the delta between two trees if the parent is present.

If you don't have easy access to 1.4.4+ packages, I have patched 1.4.3 (x86) packages here for Debian Etch (I haven't built 1.4.4 or 1.4.5 yet):

http://git-svn.yhbt.net/svn/

Eric Wong schrieb:

Thanks this sadisfies my question and its time to dive deeper into git and git-svn ...

gerhard