On Sat, 21 Aug 2010 18:37:11 +0000 Eric Wong <normalperson@xxxxxxxx> wrote: EW> > Now to my question: I thought it would be a good idea to import an svn EW> > repository with --no-metadata option as I hoped that this would avoid the EW> > rewriting of commits which happen when git topic branches are checked in EW> > into svn with "git svn dcommit". The documentation (for my 1.7.1 version) EW> > did say that: EW> EW> dcommit would have to rewrite commits anyways, since we sync the EW> usernames and commit times from SVN. You can't avoid rewriting commits EW> unless you use "git svn set-tree" (on the other hand, set-tree can be EW> unfriendly to other SVN users). Thank you for this information, I didn't think about commit times at all but if a rewrite is unavoidable because of them anyhow I'll just have to [continue to] live with it. EW> Nowadays git-filter-branch is in mainline git, and I recommend EW> using that for projects ready to drop SVN/git-svn entirely for git. Unfortunately life is not that perfect yet (but I'm working on it ;-) and I need to continue to use svn while I prefer, of course, use git for my own development. Just in case you're curious, let me describe the problem I have with commit rewriting. First, my setup is such that I have a single git-svn clone (under Linux) but as most of the projects I'm working on are cross-platform I also have git clones of this repository under Windows, Mac &c. And when I implement some feature under, say, Windows, on a branch win-work I then push it to Linux machine (where I can test that it didn't break anything under Unix) and then use "git svn dcommit" from there. So far all is well but the problem is that when I update my Windows repository master branch, it has different commits from the ones on win-work branch. So I can't e.g. "git branch -d win-work" but need to use "branch -D" (if I am perfectly sure I committed everything) or, usually, "git rebase master win-work" and only then delete the branch after git tells me that there are no differences left. All this is hardly catastrophic but if I could avoid it somehow it would be even better. Now that I know that "svn clone --no-metadata" won't help me with this I wonder if the others have any better ways of working in such setup? EW> >From 4c169c696bee06472ca3511a0f58c1c1b52b9fe9 Mon Sep 17 00:00:00 2001 EW> From: Eric Wong <normalperson@xxxxxxxx> EW> Date: Sat, 21 Aug 2010 18:52:14 +0000 EW> Subject: [PATCH] Documentation/git-svn: discourage "noMetadata" EW> EW> "noMetadata" is a limited and sometimes harmful option. EW> Recommend git-filter-branch instead (if at all) for one-shot EW> imports instead. EW> EW> This also fixes an out-of-date reference to "rev_db" format, EW> noticed by Vadim Zeitlin. EW> EW> Signed-off-by: Eric Wong <normalperson@xxxxxxxx> EW> --- EW> Documentation/git-svn.txt | 14 ++++++++++++-- EW> 1 files changed, 12 insertions(+), 2 deletions(-) EW> EW> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt EW> index 4b84d08..8abbcdc 100644 EW> --- a/Documentation/git-svn.txt EW> +++ b/Documentation/git-svn.txt EW> @@ -56,6 +56,8 @@ COMMANDS EW> as well, they take precedence. EW> --no-metadata;; EW> Set the 'noMetadata' option in the [svn-remote] config. EW> + This option is not recommended, please read the 'svn.noMetadata' EW> + section of this manpage before using this option. EW> --use-svm-props;; EW> Set the 'useSvmProps' option in the [svn-remote] config. EW> --use-svnsync-props;; EW> @@ -597,13 +599,21 @@ svn.noMetadata:: EW> svn-remote.<name>.noMetadata:: EW> This gets rid of the 'git-svn-id:' lines at the end of every commit. EW> + EW> -If you lose your .git/svn/git-svn/.rev_db file, 'git svn' will not EW> +If you lose your .git/svn/**/.rev_map.* files, 'git svn' will not EW> be able to rebuild it and you won't be able to fetch again, s/it/them/ EW> -either. This is fine for one-shot imports. EW> +either. This is sometimes useful for one-shot imports. Sorry if I sound like a broken record but this still seems to be unclear to me for the same reasons as the original text, i.e. because there is still the "if you lose ... then you won't be able to fetch again" implication (at least to me). Wouldn't something like This option can only be used for one-shot imports as 'git svn' will not be able to fetch again without metadata. Additionally, if you lose your .git/svn/**/.rev_map.* files, 'git svn' will not be able to rebuild them. be more clear? Thanks again, VZ
Attachment:
pgp4WPeGD5EBT.pgp
Description: PGP signature