{"thread":{"id":"27387","subject":"[PATCH/RFC] git-svn: New flag to add a file in empty directories","startedAt":"2011-05-17T22:00:35Z","lastAt":"2014-07-23T00:06:37Z","messageCount":11,"participants":["Ray Chen","Michael Haggerty","Eric Wong","Michael J Gruber","Gaffney"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"168085","messageId":"1305669635-10861-1-git-send-email-rchen@cs.umd.edu","threadId":"27387","inReplyTo":null,"subject":"[PATCH/RFC] git-svn: New flag to add a file in empty directories","fromName":"Ray Chen","fromEmail":"rchen@cs.umd.edu","sentAt":"2011-05-17T22:00:35Z","receivedAt":"2011-05-17T22:00:35Z","isPatch":true,"sender":{"key":"rchen@cs.umd.edu","avatar":"https://avatars.githubusercontent.com/u/1909064?v=4"},"body":"Adds the --preserve-empty-dirs flag to the clone and fetch operations that\nwill detect empty SVN directories, and create a placeholder file within them.\nThis allows \"empty\" directories to exist in the history of a Git repository.\n\nAlso adds the --placeholder-file flag to control the name of any placeholder\nfiles created.  Default value is \".gitignore\".\n\nSigned-off-by: Ray Chen <rchen@cs.umd.edu>\n---\n\nI needed this functionality when I was migrating a repository from SVN to\nGit.  It seems well known that Git only tracks files, not directories, so\nany revision I checked out would be missing the empty directories that\nexisted in the SVN repository.\n\nMy knowledge of SVN is limited, so I'm not sure how correct this patch is.\nI created a little test SVN repo, and `git svn clone --preserve-empty-dirs`\ndid the right thing, but that's hardly a complete test.\n\nSpecifically, I experimentally noticed that my patch worked with lines 4532\nand 4533 commented out.  I'm not sure what problems might occur when adding\na file Git without associated SVN properties.\n\nFinally, I added the --preserve-empty-dirs and --placeholder-file only to\nthe clone and fetch operations.  Is that appropriate?  The functionality\nis really only applicable to full migrations.  I'm not sure that the fetch\noperation should have it.\n\n git-svn.perl |   91 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-\n 1 files changed, 89 insertions(+), 2 deletions(-)\n\ndiff --git a/git-svn.perl b/git-svn.perl\nindex 0fd2fd2..64a4607 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -89,6 +89,7 @@ my ($_stdin, $_help, $_edit,\n \t$_prefix, $_no_checkout, $_url, $_verbose,\n \t$_git_format, $_commit_url, $_tag, $_merge_info);\n $Git::SVN::_follow_parent = 1;\n+$SVN::Git::Fetcher::_placeholder_filename = \".gitignore\";\n $_q ||= 0;\n my %remote_opts = ( 'username=s' => \\$Git::SVN::Prompt::_username,\n                     'config-dir=s' => \\$Git::SVN::Ra::config_dir,\n@@ -134,11 +135,19 @@ my %cmt_opts = ( 'edit|e' => \\$_edit,\n my %cmd = (\n \tfetch => [ \\&cmd_fetch, \"Download new revisions from SVN\",\n \t\t\t{ 'revision|r=s' => \\$_revision,\n+\t\t\t  'preserve-empty-dirs' =>\n+\t\t\t\t\\$SVN::Git::Fetcher::_preserve_empty_dirs,\n+\t\t\t  'placeholder-filename=s' =>\n+\t\t\t\t\\$SVN::Git::Fetcher::_placeholder_filename,\n \t\t\t  'fetch-all|all' => \\$_fetch_all,\n \t\t\t  'parent|p' => \\$_fetch_parent,\n \t\t\t   %fc_opts } ],\n \tclone => [ \\&cmd_clone, \"Initialize and fetch revisions\",\n \t\t\t{ 'revision|r=s' => \\$_revision,\n+\t\t\t  'preserve-empty-dirs' =>\n+\t\t\t\t\\$SVN::Git::Fetcher::_preserve_empty_dirs,\n+\t\t\t  'placeholder-filename=s' =>\n+\t\t\t\t\\$SVN::Git::Fetcher::_placeholder_filename,\n \t\t\t   %fc_opts, %init_opts } ],\n \tinit => [ \\&cmd_init, \"Initialize a repo for tracking\" .\n \t\t\t  \" (requires URL argument)\",\n@@ -4076,12 +4085,12 @@ sub _read_password {\n }\n \n package SVN::Git::Fetcher;\n-use vars qw/@ISA/;\n+use vars qw/@ISA $_ignore_regex $_preserve_empty_dirs $_placeholder_filename/;\n use strict;\n use warnings;\n use Carp qw/croak/;\n+use File::Basename qw/dirname/;\n use IO::File qw//;\n-use vars qw/$_ignore_regex/;\n \n # file baton members: path, mode_a, mode_b, pool, fh, blob, base\n sub new {\n@@ -4100,6 +4109,7 @@ sub new {\n \t$self->{file_prop} = {};\n \t$self->{absent_dir} = {};\n \t$self->{absent_file} = {};\n+\t$self->{deleted_gpath} = [];\n \t$self->{gii} = $git_svn->tmp_index_do(sub { Git::IndexInfo->new });\n \t$self->{pathnameencoding} = Git::config('svn.pathnameencoding');\n \t$self;\n@@ -4223,6 +4233,7 @@ sub delete_entry {\n \t\t$self->{gii}->remove($gpath);\n \t\tprint \"\\tD\\t$gpath\\n\" unless $::_q;\n \t}\n+\tpush @{$self->{deleted_gpath}}, $gpath;\n \t$self->{empty}->{$path} = 0;\n \tundef;\n }\n@@ -4273,6 +4284,7 @@ sub add_directory {\n \t\t\tchomp;\n \t\t\t$self->{gii}->remove($_);\n \t\t\tprint \"\\tD\\t$_\\n\" unless $::_q;\n+\t\t\tpush @{$self->{deleted_gpath}}, $gpath;\n \t\t}\n \t\tcommand_close_pipe($ls, $ctx);\n \t\t$self->{empty}->{$path} = 0;\n@@ -4443,12 +4455,87 @@ sub abort_edit {\n \n sub close_edit {\n \tmy $self = shift;\n+\n+\tif ($_preserve_empty_dirs) {\n+\t\tmy @empty_dirs;\n+\n+\t\t# Any entry flagged as empty that also has an associated\n+\t\t# dir_prop represents a newly created empty directory.\n+\t\tforeach my $i (keys %{$self->{empty}}) {\n+\t\t\tpush @empty_dirs, $i if exists $self->{dir_prop}->{$i};\n+\t\t}\n+\n+\t\t# Search for directories that have become empty due subsequent\n+\t\t# file deletes.\n+\t\tpush @empty_dirs, $self->find_empty_directories();\n+\n+\t\t# Finally, add a placeholder file to each empty directory.\n+\t\t$self->add_placeholder_file($_) foreach (@empty_dirs);\n+\t}\n+\n \t$self->{git_commit_ok} = 1;\n \t$self->{nr} = $self->{gii}->{nr};\n \tdelete $self->{gii};\n \t$self->SUPER::close_edit(@_);\n }\n \n+sub find_empty_directories {\n+\tmy ($self) = @_;\n+\tmy @empty_dirs;\n+\tmy %dirs = map { dirname($_) => 1 } @{$self->{deleted_gpath}};\n+\n+\tforeach my $dir (sort keys %dirs) {\n+\t\tnext if $dir eq \".\";\n+\n+\t\t# If there have been any additions to this directory, there is\n+\t\t# no reason to check if it is empty.\n+\t\tmy $skip_added = 0;\n+\t\tforeach my $t (qw/dir_prop file_prop/) {\n+\t\t\tforeach my $path (keys %{ $self->{$t} }) {\n+\t\t\t\tif (exists $self->{$t}->{dirname($path)}) {\n+\t\t\t\t\t$skip_added = 1;\n+\t\t\t\t\tlast;\n+\t\t\t\t}\n+\t\t\t}\n+\t\t\tlast if $skip_added;\n+\t\t}\n+\t\tnext if $skip_added;\n+\n+\t\t# Use `git ls-tree` to get the filenames of this directory\n+\t\t# that existed prior to this particular commit.\n+\t\tmy $ls = command('ls-tree', '-z', '--name-only',\n+\t\t\t\t $self->{c}, \"$dir/\");\n+\t\tmy %files = map { $_ => 1 } split(/\\0/, $ls);\n+\n+\t\t# Remove the filenames that were deleted during this commit.\n+\t\tdelete $files{$_} foreach (@{$self->{deleted_gpath}});\n+\n+\t\t# Report the directory if there are no filenames left.\n+\t\tpush @empty_dirs, $dir unless (scalar %files);\n+\t}\n+\t@empty_dirs;\n+}\n+\n+sub add_placeholder_file {\n+\tmy ($self, $dir) = @_;\n+\tmy $path = \"$dir/$_placeholder_filename\";\n+\tmy $gpath = $self->git_path($path);\n+\n+\tmy $fh = $::_repository->temp_acquire($gpath);\n+\tmy $hash = $::_repository->hash_and_insert_object(Git::temp_path($fh));\n+\tGit::temp_release($fh, 1);\n+\t$self->{gii}->update('100644', $hash, $gpath) or croak $!;\n+\n+\t# The following two lines don't seem to be necessary, but I'm not\n+\t# familiar enough with SVN properties to know if correctness is\n+\t# compromised without them.\n+#\t$self->{file_prop}->{$path} = $self->{dir_prop}->{$dir};\n+#\t$self->add_file($path, { 'path' => $dir }, undef, '-1');\n+\n+\t# The directory should no longer be considered empty.\n+\tdelete $self->{empty}->{$dir} if exists $self->{empty}->{$dir};\n+}\n+\n package SVN::Git::Editor;\n use vars qw/@ISA $_rmdir $_cp_similarity $_find_copies_harder $_rename_limit/;\n use strict;\n-- \n1.7.5.1\n"},{"id":"168110","messageId":"4DD373CD.6010607@alum.mit.edu","threadId":"27387","inReplyTo":"1305669635-10861-1-git-send-email-rchen@cs.umd.edu","subject":"Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-05-18T07:22:53Z","receivedAt":"2011-05-18T07:22:53Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 05/18/2011 12:00 AM, Ray Chen wrote:\n> Adds the --preserve-empty-dirs flag to the clone and fetch operations that\n> will detect empty SVN directories, and create a placeholder file within them.\n> This allows \"empty\" directories to exist in the history of a Git repository.\n> \n> Also adds the --placeholder-file flag to control the name of any placeholder\n> files created.  Default value is \".gitignore\".\n> \n> Signed-off-by: Ray Chen <rchen@cs.umd.edu>\n> ---\n> \n> I needed this functionality when I was migrating a repository from SVN to\n> Git.  It seems well known that Git only tracks files, not directories, so\n> any revision I checked out would be missing the empty directories that\n> existed in the SVN repository.\n> \n> My knowledge of SVN is limited, so I'm not sure how correct this patch is.\n> I created a little test SVN repo, and `git svn clone --preserve-empty-dirs`\n> did the right thing, but that's hardly a complete test.\n> \n> Specifically, I experimentally noticed that my patch worked with lines 4532\n> and 4533 commented out.  I'm not sure what problems might occur when adding\n> a file Git without associated SVN properties.\n> \n> Finally, I added the --preserve-empty-dirs and --placeholder-file only to\n> the clone and fetch operations.  Is that appropriate?  The functionality\n> is really only applicable to full migrations.  I'm not sure that the fetch\n> operation should have it.\n\nI'm not familiar enough with the code to critique your code, but I have\nsome questions/comments about the feature's intended behavior:\n\n1. What happens if a previously empty directory is deleted from\nSubversion?  It seems to me that consistency would demand that the\nplaceholder file be deleted so that git also forgets about the\ndirectory.  On the other hand, if the user has edited the placeholder\nfile since it was created, it might be advisable to emit a warning or error.\n\n2. What happens if, in Subversion, content is added to a previously\nempty directory?  Is the placeholder left around?\n\n3. I believe that this feature would be useful to people who are\ntracking a Subversion repository over time (not just for full\nmigrations).  What happens if the user sometimes uses the new options\nand sometimes not?  Are the missing directories that have \"accumulated\"\nsince the last invocation with --preserve-empty-dirs all added in the\nfirst commit resulting from a later use of --preserve-empty-directories,\nor are they skipped forever?  I'm talking about this scenario:\n\nSubversion                   git\n----------                   ---\nAdd empty directory \"a\"\n                             git svn fetch --preserve-empty-dirs\nAdd empty directory \"b\"\n                             git svn fetch\nAdd empty directory \"c\"\n                             git svn fetch --preserve-empty-dirs\n\nAfter the third \"git svn fetch\", does the git repository contain\ndirectory \"b\"?\n\n4. If it is a goal to support long-term tracking of a Subversion\nrepository, then it would be good to add a config option to turn on this\nfeature permanently for a git-svn repository, so that the user doesn't\nhave to enter the extra options with each command invocation.\n\n5. It might be useful to allow the placeholder files to be committed to\nSubversion, so that other git-svn users based off the same Subversion\nrepository don't have to worry about empty directories.  This would\ntypically be something that people would want to do semi-manually in\nspecific Subversion commits.  To support this user case, one could add a\nsimilar option to \"git svn mkdirs\" that causes the placeholder files to\nbe created in the working copy but not committed.  Then the user could\nreview the suggested changes, perhaps add lines to the .gitignore files,\ncommit to git, then dcommit to Subversion.\n\n6. Documentation patches would also be required.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"168116","messageId":"20110518082215.GA21899@dcvr.yhbt.net","threadId":"27387","inReplyTo":"1305669635-10861-1-git-send-email-rchen@cs.umd.edu","subject":"Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2011-05-18T08:22:15Z","receivedAt":"2011-05-18T08:22:15Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Ray Chen <rchen@cs.umd.edu> wrote:\n> I needed this functionality when I was migrating a repository from SVN to\n> Git.\n\nThis feature sounds reasonable for folks making one-shot or read-only\nmirrors with git svn.\n\n> My knowledge of SVN is limited, so I'm not sure how correct this patch is.\n> I created a little test SVN repo, and `git svn clone --preserve-empty-dirs`\n> did the right thing, but that's hardly a complete test.\n\nPlease provide an automated test case so it's easier to review (I almost\nnever see SVN repos anymore) and to ensure it stays working when other\nchanges are made.\n\n> Specifically, I experimentally noticed that my patch worked with lines 4532\n> and 4533 commented out.  I'm not sure what problems might occur when adding\n> a file Git without associated SVN properties.\n\nThese two lines?\n\n> +\t# The following two lines don't seem to be necessary, but I'm not\n> +\t# familiar enough with SVN properties to know if correctness is\n> +\t# compromised without them.\n> +#\t$self->{file_prop}->{$path} = $self->{dir_prop}->{$dir};\n> +#\t$self->add_file($path, { 'path' => $dir }, undef, '-1');\n\nIt's been years since I dealt with the SVN library, so I'm not sure I\nstill remember.  I think add_file is only for files that exist in the\nSVN side, not sure about the file_prop/dir_prop assignment, either.\n\n(more in my reply to Michael's email)\n\n-- \nEric Wong\n"},{"id":"168117","messageId":"20110518083314.GA22204@dcvr.yhbt.net","threadId":"27387","inReplyTo":"4DD373CD.6010607@alum.mit.edu","subject":"Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2011-05-18T08:33:14Z","receivedAt":"2011-05-18T08:33:14Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Michael Haggerty <mhagger@alum.mit.edu> wrote:\n<snip> 1..3 are all very good points\n\n> 4. If it is a goal to support long-term tracking of a Subversion\n> repository, then it would be good to add a config option to turn on this\n> feature permanently for a git-svn repository, so that the user doesn't\n> have to enter the extra options with each command invocation.\n\nCommand-line options should be automatically converted into config file\noptions inside git svn.  We should however discourage this from getting\nmixed...\n\n> 5. It might be useful to allow the placeholder files to be committed to\n> Subversion, so that other git-svn users based off the same Subversion\n> repository don't have to worry about empty directories.  This would\n> typically be something that people would want to do semi-manually in\n> specific Subversion commits.  To support this user case, one could add a\n> similar option to \"git svn mkdirs\" that causes the placeholder files to\n> be created in the working copy but not committed.  Then the user could\n> review the suggested changes, perhaps add lines to the .gitignore files,\n> commit to git, then dcommit to Subversion.\n\nNo, too hard and error-prone, I think.\n\nThis would require tracking which .gitignore files are git-only and\nwhich are not (some SVN repos have .gitignore files explicitly checked\nin, but that should /always/ be done explicitly by the user every time).\n\nI would go as far as to have a flag to disable dcommit (and set-tree) on\nany repo that uses this placeholder feature.  SVN-only folks could be\nvery unhappy to see placeholder files, especially in some cases\nwhere placeholders may break builds or cause information leaks.\n\n\nI strongly believe git-svn should leave no trace.  Nobody but the user\nusing git-svn should know they're using git-svn to interact with an SVN\nrepo.  This allows users to stay under the radar of any idiotic rules\n(or knee-jerk reactions of FUD) their organization may have against\nusing non-standard SVN clients.  So far, it's worked out pretty well,\ngit-svn users slowly and quietly develop clout and influence to migrate\ntheir repos from SVN to git.\n\n> 6. Documentation patches would also be required.\n\nAgreed, along with automated test cases.\n\n-- \nEric Wong\n"},{"id":"168124","messageId":"4DD38DEE.4080604@drmicha.warpmail.net","threadId":"27387","inReplyTo":"20110518083314.GA22204@dcvr.yhbt.net","subject":"Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-05-18T09:14:22Z","receivedAt":"2011-05-18T09:14:22Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Eric Wong venit, vidit, dixit 18.05.2011 10:33:\n> Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> <snip> 1..3 are all very good points\n> \n>> 4. If it is a goal to support long-term tracking of a Subversion\n>> repository, then it would be good to add a config option to turn on this\n>> feature permanently for a git-svn repository, so that the user doesn't\n>> have to enter the extra options with each command invocation.\n> \n> Command-line options should be automatically converted into config file\n> options inside git svn.  We should however discourage this from getting\n> mixed...\n> \n>> 5. It might be useful to allow the placeholder files to be committed to\n>> Subversion, so that other git-svn users based off the same Subversion\n>> repository don't have to worry about empty directories.  This would\n>> typically be something that people would want to do semi-manually in\n>> specific Subversion commits.  To support this user case, one could add a\n>> similar option to \"git svn mkdirs\" that causes the placeholder files to\n>> be created in the working copy but not committed.  Then the user could\n>> review the suggested changes, perhaps add lines to the .gitignore files,\n>> commit to git, then dcommit to Subversion.\n> \n> No, too hard and error-prone, I think.\n> \n> This would require tracking which .gitignore files are git-only and\n> which are not (some SVN repos have .gitignore files explicitly checked\n> in, but that should /always/ be done explicitly by the user every time).\n> \n> I would go as far as to have a flag to disable dcommit (and set-tree) on\n> any repo that uses this placeholder feature.  SVN-only folks could be\n> very unhappy to see placeholder files, especially in some cases\n> where placeholders may break builds or cause information leaks.\n> \n> \n> I strongly believe git-svn should leave no trace.  Nobody but the user\n> using git-svn should know they're using git-svn to interact with an SVN\n> repo.  This allows users to stay under the radar of any idiotic rules\n> (or knee-jerk reactions of FUD) their organization may have against\n> using non-standard SVN clients.  So far, it's worked out pretty well,\n> git-svn users slowly and quietly develop clout and influence to migrate\n> their repos from SVN to git.\n\ngit-svn's maintenance of these files would be simpler if we used a\nspecial file for that, say .git-svn-empty-dir, and teach dcommit to\nignore it. That way git clones can share it and git svn dcommit is\nunimpaired. The only problem occurs when a new git-svn commits these,\nand old git clones that and an old git-svn dcommits from that clone.\n\n>> 6. Documentation patches would also be required.\n> \n> Agreed, along with automated test cases.\n> \n\nMichael\n"},{"id":"168127","messageId":"BANLkTi=of41DdZAqxAZkgjuuqo3bVpjexA@mail.gmail.com","threadId":"27387","inReplyTo":"4DD373CD.6010607@alum.mit.edu","subject":"Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories","fromName":"Ray Chen","fromEmail":"rchen@cs.umd.edu","sentAt":"2011-05-18T10:46:25Z","receivedAt":"2011-05-18T10:46:25Z","isPatch":true,"sender":{"key":"rchen@cs.umd.edu","avatar":"https://avatars.githubusercontent.com/u/1909064?v=4"},"body":"On Wed, May 18, 2011 at 3:22 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n>\n> I'm not familiar enough with the code to critique your code, but I have\n> some questions/comments about the feature's intended behavior:\n>\n> 1. What happens if a previously empty directory is deleted from\n> Subversion?  It seems to me that consistency would demand that the\n> placeholder file be deleted so that git also forgets about the\n> directory.  On the other hand, if the user has edited the placeholder\n> file since it was created, it might be advisable to emit a warning or error.\n>\nWhen directories are deleted from a Subversion repository (empty or\nnot), the corresponding Git directory and all its constituent files\nare removed one by one.  This takes care of any placeholder files that\nmay have been added.\n\nThis happens inside SVN::Git::Fetcher::delete_entry around line 4210.\n\n> 2. What happens if, in Subversion, content is added to a previously\n> empty directory?  Is the placeholder left around?\n>\nTrue, the placeholder sticks around in this case.  It wouldn't be hard\nto track when a placeholder file is generated and remove it when it's\nno longer needed.\n\nTracking the placeholder files would also be useful for namespace\ncollisions.  For example, if a Subversion repository adds a .gitignore\nfile to a previously committed empty directory.  The Subversion add\nwould need to be translated into a Git modification.  I'm not sure how\nto store this information in the long-term tracking case, though.\n\n> 3. I believe that this feature would be useful to people who are\n> tracking a Subversion repository over time (not just for full\n> migrations).  What happens if the user sometimes uses the new options\n> and sometimes not?  Are the missing directories that have \"accumulated\"\n> since the last invocation with --preserve-empty-dirs all added in the\n> first commit resulting from a later use of --preserve-empty-directories,\n> or are they skipped forever?  I'm talking about this scenario:\n>\n> Subversion                   git\n> ----------                   ---\n> Add empty directory \"a\"\n>                             git svn fetch --preserve-empty-dirs\n> Add empty directory \"b\"\n>                             git svn fetch\n> Add empty directory \"c\"\n>                             git svn fetch --preserve-empty-dirs\n>\n> After the third \"git svn fetch\", does the git repository contain\n> directory \"b\"?\n>\nIn this case, the git repository would not contain the \"b\" directory,\nbut it would exist in the user's working copy without a placeholder\nfile.  I can only think of two situations when this is inappropriate.\nFirst, if the user checks out earlier revisions, the empty directories\nwould persist.  Second, if anybody clones the Git repository, they'd\nbe missing the empty directories.\n\nHow problematic are these two cases?  I think re-fetching everything\nfrom the Subversion repository is the only way to fix this.\n\nIf support for long-term tracking is deemed desirable, then maybe this\nfeature should be on by default.  Otherwise, you increase the chance\nthat repository data will be irrevocably damaged.\n\n- Ray\n"},{"id":"168128","messageId":"BANLkTimGrkL2KjGC652tr3=Y0h02C_fzaQ@mail.gmail.com","threadId":"27387","inReplyTo":"20110518083314.GA22204@dcvr.yhbt.net","subject":"Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories","fromName":"Ray Chen","fromEmail":"rchen@cs.umd.edu","sentAt":"2011-05-18T10:59:23Z","receivedAt":"2011-05-18T10:59:23Z","isPatch":true,"sender":{"key":"rchen@cs.umd.edu","avatar":"https://avatars.githubusercontent.com/u/1909064?v=4"},"body":"On Wed, May 18, 2011 at 4:33 AM, Eric Wong <normalperson@yhbt.net> wrote:\n>\n>> 4. If it is a goal to support long-term tracking of a Subversion\n>> repository, then it would be good to add a config option to turn on this\n>> feature permanently for a git-svn repository, so that the user doesn't\n>> have to enter the extra options with each command invocation.\n>\n> Command-line options should be automatically converted into config file\n> options inside git svn.  We should however discourage this from getting\n> mixed...\n>\nI'm not sure what you mean by this.  Do you mean that options\nshouldn't be settable both on the command line and the config file?  I\nthink this situation already exists with the --no-metadata option.\n\n>\n>> 6. Documentation patches would also be required.\n>\n> Agreed, along with automated test cases.\n>\nNo problem.  Might take a while, though.  I haven't looked at the test\ncase system yet.\n\n- Ray\n"},{"id":"168129","messageId":"BANLkTinvFKAsh5N92rSH26Y12dV6bPQFUw@mail.gmail.com","threadId":"27387","inReplyTo":"4DD38DEE.4080604@drmicha.warpmail.net","subject":"Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories","fromName":"Ray Chen","fromEmail":"rchen@cs.umd.edu","sentAt":"2011-05-18T11:10:23Z","receivedAt":"2011-05-18T11:10:23Z","isPatch":true,"sender":{"key":"rchen@cs.umd.edu","avatar":"https://avatars.githubusercontent.com/u/1909064?v=4"},"body":"On Wed, May 18, 2011 at 5:14 AM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n>>\n>> I strongly believe git-svn should leave no trace.  Nobody but the user\n>> using git-svn should know they're using git-svn to interact with an SVN\n>> repo.  This allows users to stay under the radar of any idiotic rules\n>> (or knee-jerk reactions of FUD) their organization may have against\n>> using non-standard SVN clients.  So far, it's worked out pretty well,\n>> git-svn users slowly and quietly develop clout and influence to migrate\n>> their repos from SVN to git.\n>\n> git-svn's maintenance of these files would be simpler if we used a\n> special file for that, say .git-svn-empty-dir, and teach dcommit to\n> ignore it. That way git clones can share it and git svn dcommit is\n> unimpaired. The only problem occurs when a new git-svn commits these,\n> and old git clones that and an old git-svn dcommits from that clone.\n>\n\nI'll let people more experienced than I come to a conclusion on this one.\n\nI can say I'm loath to spend a lot of time on this, given that it\nmight all be replaced within two months by Dmitry Ivankov's GSoC\nproject.\n\n- Ray\n"},{"id":"168157","messageId":"20110518200139.GB10697@dcvr.yhbt.net","threadId":"27387","inReplyTo":"BANLkTimGrkL2KjGC652tr3=Y0h02C_fzaQ@mail.gmail.com","subject":"Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2011-05-18T20:01:39Z","receivedAt":"2011-05-18T20:01:39Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Ray Chen <rchen@cs.umd.edu> wrote:\n> On Wed, May 18, 2011 at 4:33 AM, Eric Wong <normalperson@yhbt.net> wrote:\n> >\n> >> 4. If it is a goal to support long-term tracking of a Subversion\n> >> repository, then it would be good to add a config option to turn on this\n> >> feature permanently for a git-svn repository, so that the user doesn't\n> >> have to enter the extra options with each command invocation.\n> >\n> > Command-line options should be automatically converted into config file\n> > options inside git svn.  We should however discourage this from getting\n> > mixed...\n> >\n> I'm not sure what you mean by this.  Do you mean that options\n> shouldn't be settable both on the command line and the config file?  I\n> think this situation already exists with the --no-metadata option.\n\ngit-svn automatically understands configuration options based on the\ncommand-line options (see sub read_get_config).\n\n-- \nEric Wong\n"},{"id":"168184","messageId":"4DD48A5A.8030905@alum.mit.edu","threadId":"27387","inReplyTo":"20110518083314.GA22204@dcvr.yhbt.net","subject":"Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-05-19T03:11:22Z","receivedAt":"2011-05-19T03:11:22Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 05/18/2011 10:33 AM, Eric Wong wrote:\n> Michael Haggerty <mhagger@alum.mit.edu> wrote:\n>> 5. It might be useful to allow the placeholder files to be committed to\n>> Subversion, so that other git-svn users based off the same Subversion\n>> repository don't have to worry about empty directories.  This would\n>> typically be something that people would want to do semi-manually in\n>> specific Subversion commits.  To support this user case, one could add a\n>> similar option to \"git svn mkdirs\" that causes the placeholder files to\n>> be created in the working copy but not committed.  Then the user could\n>> review the suggested changes, perhaps add lines to the .gitignore files,\n>> commit to git, then dcommit to Subversion.\n> \n> No, too hard and error-prone, I think.\n> \n> This would require tracking which .gitignore files are git-only and\n> which are not (some SVN repos have .gitignore files explicitly checked\n> in, but that should /always/ be done explicitly by the user every time).\n\nI agree that the checkin should not be done automatically.  But it is\nexactly to assist the explicit (manual) maintenance of placeholder files\nin Subversion that this feature could be useful.\n\n> I would go as far as to have a flag to disable dcommit (and set-tree) on\n> any repo that uses this placeholder feature.  SVN-only folks could be\n> very unhappy to see placeholder files, especially in some cases\n> where placeholders may break builds or cause information leaks.\n> \n> I strongly believe git-svn should leave no trace.  Nobody but the user\n> using git-svn should know they're using git-svn to interact with an SVN\n> repo.  This allows users to stay under the radar of any idiotic rules\n> (or knee-jerk reactions of FUD) their organization may have against\n> using non-standard SVN clients.  So far, it's worked out pretty well,\n> git-svn users slowly and quietly develop clout and influence to migrate\n> their repos from SVN to git.\n\nIndeed, by default git-svn should leave no trace.  But there are other\nworkplaces (mine included) where the use of git-svn is welcomed and\nsupported.  For us, features like \"git svn create-ignore\" are used to\nmaintain .gitignore files that are committed to Subversion.  Perhaps\nthere needs to be a repository-wide flag to distinguish between:\n\n\"conversion mode\" -- This mode would be intended for full conversions to\ngit.  Placeholders created for empty directories, svn:ignore properties\nconverted automatically into .gitignore files, etc.  These actions would\nhappen automatically whenever a Subversion commit is retrieved and the\nchanges would be added to the git history as if they had happened in the\ncorresponding SVN commit.  \"git svn dcommit\" would be forbidden from\nsuch repositories.\n\n\"working mode\" -- This mode would support the use of git-svn as a\nfront-end to Subversion.  It would never push git-related changes to\nSubversion except at the explicit request of the user.  In this mode,\nthere would be commands (like \"git svn create-ignore\") to create git\naids like placeholders and .gitignore files in the working copy, but\nonly at the explicit request of the user, and these changes would never\nbe committed automatically.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"246537","messageId":"1406073997070-7615634.post@n2.nabble.com","threadId":"27387","inReplyTo":"1305669635-10861-1-git-send-email-rchen@cs.umd.edu","subject":"Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories","fromName":"Gaffney","fromEmail":"ryanmgaffney@gmail.com","sentAt":"2014-07-23T00:06:37Z","receivedAt":"2014-07-23T00:06:37Z","isPatch":true,"sender":{"key":"ryanmgaffney@gmail.com","avatar":null},"body":"Any idea why this parameter would slow down a clone so severely?  I am\nexperiencing clone slowdown by 5x+ after adding this parameter, which is not\ncool given the size of the repository and the urgency of finishing the\nmigration.\n\n\n\n--\nView this message in context: http://git.661346.n2.nabble.com/PATCH-RFC-git-svn-New-flag-to-add-a-file-in-empty-directories-tp6375393p7615634.html\nSent from the git mailing list archive at Nabble.com.\n"}]}