Eric Wong venit, vidit, dixit 18.05.2011 10:33: > Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > <snip> 1..3 are all very good points > >> 4. If it is a goal to support long-term tracking of a Subversion >> repository, then it would be good to add a config option to turn on this >> feature permanently for a git-svn repository, so that the user doesn't >> have to enter the extra options with each command invocation. > > Command-line options should be automatically converted into config file > options inside git svn. We should however discourage this from getting > mixed... > >> 5. It might be useful to allow the placeholder files to be committed to >> Subversion, so that other git-svn users based off the same Subversion >> repository don't have to worry about empty directories. This would >> typically be something that people would want to do semi-manually in >> specific Subversion commits. To support this user case, one could add a >> similar option to "git svn mkdirs" that causes the placeholder files to >> be created in the working copy but not committed. Then the user could >> review the suggested changes, perhaps add lines to the .gitignore files, >> commit to git, then dcommit to Subversion. > > No, too hard and error-prone, I think. > > This would require tracking which .gitignore files are git-only and > which are not (some SVN repos have .gitignore files explicitly checked > in, but that should /always/ be done explicitly by the user every time). > > I would go as far as to have a flag to disable dcommit (and set-tree) on > any repo that uses this placeholder feature. SVN-only folks could be > very unhappy to see placeholder files, especially in some cases > where placeholders may break builds or cause information leaks. > > > I strongly believe git-svn should leave no trace. Nobody but the user > using git-svn should know they're using git-svn to interact with an SVN > repo. This allows users to stay under the radar of any idiotic rules > (or knee-jerk reactions of FUD) their organization may have against > using non-standard SVN clients. So far, it's worked out pretty well, > git-svn users slowly and quietly develop clout and influence to migrate > their repos from SVN to git. git-svn's maintenance of these files would be simpler if we used a special file for that, say .git-svn-empty-dir, and teach dcommit to ignore it. That way git clones can share it and git svn dcommit is unimpaired. The only problem occurs when a new git-svn commits these, and old git clones that and an old git-svn dcommits from that clone. >> 6. Documentation patches would also be required. > > Agreed, along with automated test cases. > Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html