git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: Vadim Zeitlin <vz-git@zeitlins.org>
Cc: git@vger.kernel.org
Subject: Re: using git-svn with --no-metadata
Date: Sat, 21 Aug 2010 18:37:11 +0000	[thread overview]
Message-ID: <20100821183711.GA14986@dcvr.yhbt.net> (raw)
In-Reply-To: <E1OmnCj-0001Z7-2U@smtp.tt-solutions.com>

Vadim Zeitlin <vz-git@zeitlins.org> wrote:
>  Hello,
> 
>  First of all, let me use this opportunity to thank you for writing
> git-svn, it's the best thing since, well, probably git itself! Second,
> I'm sorry to bother you directly but I simply couldn't find any mailing
> list for git-svn and I wasn't sure if this was appropriate for the git
> mailing list itself. If I was wrong about not posting this there, please
> feel free to redirect/reply to git list if you prefer to discuss it there
> (I'd appreciate if you could still cc me in this case though).

Hello Vadim, you're welcome!

git-svn has always used the git mailing list.  Feel free to Cc
maintainers of particular subsections even when posting to the mailing
list, too.  The mailing list gets a lot of traffic, so we always
Cc folks who are relevant to the discussion.

>  Now to my question: I thought it would be a good idea to import an svn
> repository with --no-metadata option as I hoped that this would avoid the
> rewriting of commits which happen when git topic branches are checked in
> into svn with "git svn dcommit". The documentation (for my 1.7.1 version)
> did say that:

dcommit would have to rewrite commits anyways, since we sync the
usernames and commit times from SVN.  You can't avoid rewriting commits
unless you use "git svn set-tree" (on the other hand, set-tree can be
unfriendly to other SVN users).

> 	If you lose your .git/svn/git-svn/.rev_db file, git svn will not be
> 	able to rebuild it and you won't be able to fetch again, either.

> but I understood it as meaning that I wouldn't be able to fetch again if
> the file was lost (the file name appears to be wrong BTW, since the switch
> to rev_map from rev_db some time ago) and thought that it was ok as long as
> I took care to backup the .git/svn contents regularly. Apparently I was
> wrong as "git svn fetch" doesn't work even immediately after the import and
> looking at the code I see that working_head_info() only ever uses
> git-svn-id: lines in the commit messages and never rev_{db,map} files.
> 
>  So -- finally -- the questions are:
> 
> 1. Is this indeed the case, i.e. is importing from svn really impossible
>    with --no-metadata even if no files are lost? If so, I think it would
>    be nice to make the property description in the man page more clear.

rev_map (and rev_db before it) are designed for mapping SVN revision
numbers into git SHA1 identifiers.  rev_db used a simple but
space-inefficient offset lookup based on the SVN revision number.
rev_map uses a binary search also based on the SVN revision number.

> 2. Is it possible to implement getting the working head info from the
>    cached revision mappings instead of extracting it from the comments?
>    If so, would it be worth looking into doing this or is it something
>    that is doomed to fail anyhow?

It's possible to do a reverse mapping inefficiently (O(n)) by scanning
the values of the SHA1 commits.  You can add a hash database on disk,
too.  I don't think either is worth the effort in maintenance, though.
Nowadays git-filter-branch is in mainline git, and I recommend
using that for projects ready to drop SVN/git-svn entirely for git.

I'll update the docs accordingly.

-- 
Eric Wong

       reply	other threads:[~2010-08-21 18:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1OmnCj-0001Z7-2U@smtp.tt-solutions.com>
2010-08-21 18:37 ` Eric Wong [this message]
2010-08-21 19:07   ` using git-svn with --no-metadata Eric Wong
2010-08-21 20:03     ` Andreas Schwab
2010-08-21 20:17     ` Re[2]: " Vadim Zeitlin
2010-08-23  2:22       ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100821183711.GA14986@dcvr.yhbt.net \
    --to=normalperson@yhbt.net \
    --cc=git@vger.kernel.org \
    --cc=vz-git@zeitlins.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).