All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH/RFC] git-svn: New flag to add a file in empty directories
@ 2011-05-17 22:00 Ray Chen
  2011-05-18  7:22 ` Michael Haggerty
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Ray Chen @ 2011-05-17 22:00 UTC (permalink / raw)
  To: git; +Cc: Eric Wong, Ray Chen

Adds the --preserve-empty-dirs flag to the clone and fetch operations that
will detect empty SVN directories, and create a placeholder file within them.
This allows "empty" directories to exist in the history of a Git repository.

Also adds the --placeholder-file flag to control the name of any placeholder
files created.  Default value is ".gitignore".

Signed-off-by: Ray Chen <rchen@cs.umd.edu>
---

I needed this functionality when I was migrating a repository from SVN to
Git.  It seems well known that Git only tracks files, not directories, so
any revision I checked out would be missing the empty directories that
existed in the SVN repository.

My knowledge of SVN is limited, so I'm not sure how correct this patch is.
I created a little test SVN repo, and `git svn clone --preserve-empty-dirs`
did the right thing, but that's hardly a complete test.

Specifically, I experimentally noticed that my patch worked with lines 4532
and 4533 commented out.  I'm not sure what problems might occur when adding
a file Git without associated SVN properties.

Finally, I added the --preserve-empty-dirs and --placeholder-file only to
the clone and fetch operations.  Is that appropriate?  The functionality
is really only applicable to full migrations.  I'm not sure that the fetch
operation should have it.

 git-svn.perl |   91 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 89 insertions(+), 2 deletions(-)

diff --git a/git-svn.perl b/git-svn.perl
index 0fd2fd2..64a4607 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -89,6 +89,7 @@ my ($_stdin, $_help, $_edit,
 	$_prefix, $_no_checkout, $_url, $_verbose,
 	$_git_format, $_commit_url, $_tag, $_merge_info);
 $Git::SVN::_follow_parent = 1;
+$SVN::Git::Fetcher::_placeholder_filename = ".gitignore";
 $_q ||= 0;
 my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
                     'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -134,11 +135,19 @@ my %cmt_opts = ( 'edit|e' => \$_edit,
 my %cmd = (
 	fetch => [ \&cmd_fetch, "Download new revisions from SVN",
 			{ 'revision|r=s' => \$_revision,
+			  'preserve-empty-dirs' =>
+				\$SVN::Git::Fetcher::_preserve_empty_dirs,
+			  'placeholder-filename=s' =>
+				\$SVN::Git::Fetcher::_placeholder_filename,
 			  'fetch-all|all' => \$_fetch_all,
 			  'parent|p' => \$_fetch_parent,
 			   %fc_opts } ],
 	clone => [ \&cmd_clone, "Initialize and fetch revisions",
 			{ 'revision|r=s' => \$_revision,
+			  'preserve-empty-dirs' =>
+				\$SVN::Git::Fetcher::_preserve_empty_dirs,
+			  'placeholder-filename=s' =>
+				\$SVN::Git::Fetcher::_placeholder_filename,
 			   %fc_opts, %init_opts } ],
 	init => [ \&cmd_init, "Initialize a repo for tracking" .
 			  " (requires URL argument)",
@@ -4076,12 +4085,12 @@ sub _read_password {
 }
 
 package SVN::Git::Fetcher;
-use vars qw/@ISA/;
+use vars qw/@ISA $_ignore_regex $_preserve_empty_dirs $_placeholder_filename/;
 use strict;
 use warnings;
 use Carp qw/croak/;
+use File::Basename qw/dirname/;
 use IO::File qw//;
-use vars qw/$_ignore_regex/;
 
 # file baton members: path, mode_a, mode_b, pool, fh, blob, base
 sub new {
@@ -4100,6 +4109,7 @@ sub new {
 	$self->{file_prop} = {};
 	$self->{absent_dir} = {};
 	$self->{absent_file} = {};
+	$self->{deleted_gpath} = [];
 	$self->{gii} = $git_svn->tmp_index_do(sub { Git::IndexInfo->new });
 	$self->{pathnameencoding} = Git::config('svn.pathnameencoding');
 	$self;
@@ -4223,6 +4233,7 @@ sub delete_entry {
 		$self->{gii}->remove($gpath);
 		print "\tD\t$gpath\n" unless $::_q;
 	}
+	push @{$self->{deleted_gpath}}, $gpath;
 	$self->{empty}->{$path} = 0;
 	undef;
 }
@@ -4273,6 +4284,7 @@ sub add_directory {
 			chomp;
 			$self->{gii}->remove($_);
 			print "\tD\t$_\n" unless $::_q;
+			push @{$self->{deleted_gpath}}, $gpath;
 		}
 		command_close_pipe($ls, $ctx);
 		$self->{empty}->{$path} = 0;
@@ -4443,12 +4455,87 @@ sub abort_edit {
 
 sub close_edit {
 	my $self = shift;
+
+	if ($_preserve_empty_dirs) {
+		my @empty_dirs;
+
+		# Any entry flagged as empty that also has an associated
+		# dir_prop represents a newly created empty directory.
+		foreach my $i (keys %{$self->{empty}}) {
+			push @empty_dirs, $i if exists $self->{dir_prop}->{$i};
+		}
+
+		# Search for directories that have become empty due subsequent
+		# file deletes.
+		push @empty_dirs, $self->find_empty_directories();
+
+		# Finally, add a placeholder file to each empty directory.
+		$self->add_placeholder_file($_) foreach (@empty_dirs);
+	}
+
 	$self->{git_commit_ok} = 1;
 	$self->{nr} = $self->{gii}->{nr};
 	delete $self->{gii};
 	$self->SUPER::close_edit(@_);
 }
 
+sub find_empty_directories {
+	my ($self) = @_;
+	my @empty_dirs;
+	my %dirs = map { dirname($_) => 1 } @{$self->{deleted_gpath}};
+
+	foreach my $dir (sort keys %dirs) {
+		next if $dir eq ".";
+
+		# If there have been any additions to this directory, there is
+		# no reason to check if it is empty.
+		my $skip_added = 0;
+		foreach my $t (qw/dir_prop file_prop/) {
+			foreach my $path (keys %{ $self->{$t} }) {
+				if (exists $self->{$t}->{dirname($path)}) {
+					$skip_added = 1;
+					last;
+				}
+			}
+			last if $skip_added;
+		}
+		next if $skip_added;
+
+		# Use `git ls-tree` to get the filenames of this directory
+		# that existed prior to this particular commit.
+		my $ls = command('ls-tree', '-z', '--name-only',
+				 $self->{c}, "$dir/");
+		my %files = map { $_ => 1 } split(/\0/, $ls);
+
+		# Remove the filenames that were deleted during this commit.
+		delete $files{$_} foreach (@{$self->{deleted_gpath}});
+
+		# Report the directory if there are no filenames left.
+		push @empty_dirs, $dir unless (scalar %files);
+	}
+	@empty_dirs;
+}
+
+sub add_placeholder_file {
+	my ($self, $dir) = @_;
+	my $path = "$dir/$_placeholder_filename";
+	my $gpath = $self->git_path($path);
+
+	my $fh = $::_repository->temp_acquire($gpath);
+	my $hash = $::_repository->hash_and_insert_object(Git::temp_path($fh));
+	Git::temp_release($fh, 1);
+	$self->{gii}->update('100644', $hash, $gpath) or croak $!;
+
+	# The following two lines don't seem to be necessary, but I'm not
+	# familiar enough with SVN properties to know if correctness is
+	# compromised without them.
+#	$self->{file_prop}->{$path} = $self->{dir_prop}->{$dir};
+#	$self->add_file($path, { 'path' => $dir }, undef, '-1');
+
+	# The directory should no longer be considered empty.
+	delete $self->{empty}->{$dir} if exists $self->{empty}->{$dir};
+}
+
 package SVN::Git::Editor;
 use vars qw/@ISA $_rmdir $_cp_similarity $_find_copies_harder $_rename_limit/;
 use strict;
-- 
1.7.5.1

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories
  2011-05-17 22:00 [PATCH/RFC] git-svn: New flag to add a file in empty directories Ray Chen
@ 2011-05-18  7:22 ` Michael Haggerty
  2011-05-18  8:33   ` Eric Wong
  2011-05-18 10:46   ` Ray Chen
  2011-05-18  8:22 ` Eric Wong
  2014-07-23  0:06 ` Gaffney
  2 siblings, 2 replies; 11+ messages in thread
From: Michael Haggerty @ 2011-05-18  7:22 UTC (permalink / raw)
  To: Ray Chen; +Cc: git, Eric Wong

On 05/18/2011 12:00 AM, Ray Chen wrote:
> Adds the --preserve-empty-dirs flag to the clone and fetch operations that
> will detect empty SVN directories, and create a placeholder file within them.
> This allows "empty" directories to exist in the history of a Git repository.
> 
> Also adds the --placeholder-file flag to control the name of any placeholder
> files created.  Default value is ".gitignore".
> 
> Signed-off-by: Ray Chen <rchen@cs.umd.edu>
> ---
> 
> I needed this functionality when I was migrating a repository from SVN to
> Git.  It seems well known that Git only tracks files, not directories, so
> any revision I checked out would be missing the empty directories that
> existed in the SVN repository.
> 
> My knowledge of SVN is limited, so I'm not sure how correct this patch is.
> I created a little test SVN repo, and `git svn clone --preserve-empty-dirs`
> did the right thing, but that's hardly a complete test.
> 
> Specifically, I experimentally noticed that my patch worked with lines 4532
> and 4533 commented out.  I'm not sure what problems might occur when adding
> a file Git without associated SVN properties.
> 
> Finally, I added the --preserve-empty-dirs and --placeholder-file only to
> the clone and fetch operations.  Is that appropriate?  The functionality
> is really only applicable to full migrations.  I'm not sure that the fetch
> operation should have it.

I'm not familiar enough with the code to critique your code, but I have
some questions/comments about the feature's intended behavior:

1. What happens if a previously empty directory is deleted from
Subversion?  It seems to me that consistency would demand that the
placeholder file be deleted so that git also forgets about the
directory.  On the other hand, if the user has edited the placeholder
file since it was created, it might be advisable to emit a warning or error.

2. What happens if, in Subversion, content is added to a previously
empty directory?  Is the placeholder left around?

3. I believe that this feature would be useful to people who are
tracking a Subversion repository over time (not just for full
migrations).  What happens if the user sometimes uses the new options
and sometimes not?  Are the missing directories that have "accumulated"
since the last invocation with --preserve-empty-dirs all added in the
first commit resulting from a later use of --preserve-empty-directories,
or are they skipped forever?  I'm talking about this scenario:

Subversion                   git
----------                   ---
Add empty directory "a"
                             git svn fetch --preserve-empty-dirs
Add empty directory "b"
                             git svn fetch
Add empty directory "c"
                             git svn fetch --preserve-empty-dirs

After the third "git svn fetch", does the git repository contain
directory "b"?

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.

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.

6. Documentation patches would also be required.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories
  2011-05-17 22:00 [PATCH/RFC] git-svn: New flag to add a file in empty directories Ray Chen
  2011-05-18  7:22 ` Michael Haggerty
@ 2011-05-18  8:22 ` Eric Wong
  2014-07-23  0:06 ` Gaffney
  2 siblings, 0 replies; 11+ messages in thread
From: Eric Wong @ 2011-05-18  8:22 UTC (permalink / raw)
  To: Ray Chen; +Cc: git

Ray Chen <rchen@cs.umd.edu> wrote:
> I needed this functionality when I was migrating a repository from SVN to
> Git.

This feature sounds reasonable for folks making one-shot or read-only
mirrors with git svn.

> My knowledge of SVN is limited, so I'm not sure how correct this patch is.
> I created a little test SVN repo, and `git svn clone --preserve-empty-dirs`
> did the right thing, but that's hardly a complete test.

Please provide an automated test case so it's easier to review (I almost
never see SVN repos anymore) and to ensure it stays working when other
changes are made.

> Specifically, I experimentally noticed that my patch worked with lines 4532
> and 4533 commented out.  I'm not sure what problems might occur when adding
> a file Git without associated SVN properties.

These two lines?

> +	# The following two lines don't seem to be necessary, but I'm not
> +	# familiar enough with SVN properties to know if correctness is
> +	# compromised without them.
> +#	$self->{file_prop}->{$path} = $self->{dir_prop}->{$dir};
> +#	$self->add_file($path, { 'path' => $dir }, undef, '-1');

It's been years since I dealt with the SVN library, so I'm not sure I
still remember.  I think add_file is only for files that exist in the
SVN side, not sure about the file_prop/dir_prop assignment, either.

(more in my reply to Michael's email)

-- 
Eric Wong

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories
  2011-05-18  7:22 ` Michael Haggerty
@ 2011-05-18  8:33   ` Eric Wong
  2011-05-18  9:14     ` Michael J Gruber
                       ` (2 more replies)
  2011-05-18 10:46   ` Ray Chen
  1 sibling, 3 replies; 11+ messages in thread
From: Eric Wong @ 2011-05-18  8:33 UTC (permalink / raw)
  To: Michael Haggerty; +Cc: Ray Chen, git

Michael Haggerty <mhagger@alum.mit.edu> 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.

> 6. Documentation patches would also be required.

Agreed, along with automated test cases.

-- 
Eric Wong

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories
  2011-05-18  8:33   ` Eric Wong
@ 2011-05-18  9:14     ` Michael J Gruber
  2011-05-18 11:10       ` Ray Chen
  2011-05-18 10:59     ` Ray Chen
  2011-05-19  3:11     ` Michael Haggerty
  2 siblings, 1 reply; 11+ messages in thread
From: Michael J Gruber @ 2011-05-18  9:14 UTC (permalink / raw)
  To: Eric Wong; +Cc: Michael Haggerty, Ray Chen, git

Eric Wong venit, vidit, dixit 18.05.2011 10:33:
> Michael Haggerty <mhagger@alum.mit.edu> 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories
  2011-05-18  7:22 ` Michael Haggerty
  2011-05-18  8:33   ` Eric Wong
@ 2011-05-18 10:46   ` Ray Chen
  1 sibling, 0 replies; 11+ messages in thread
From: Ray Chen @ 2011-05-18 10:46 UTC (permalink / raw)
  To: Michael Haggerty; +Cc: git, Eric Wong

On Wed, May 18, 2011 at 3:22 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>
> I'm not familiar enough with the code to critique your code, but I have
> some questions/comments about the feature's intended behavior:
>
> 1. What happens if a previously empty directory is deleted from
> Subversion?  It seems to me that consistency would demand that the
> placeholder file be deleted so that git also forgets about the
> directory.  On the other hand, if the user has edited the placeholder
> file since it was created, it might be advisable to emit a warning or error.
>
When directories are deleted from a Subversion repository (empty or
not), the corresponding Git directory and all its constituent files
are removed one by one.  This takes care of any placeholder files that
may have been added.

This happens inside SVN::Git::Fetcher::delete_entry around line 4210.

> 2. What happens if, in Subversion, content is added to a previously
> empty directory?  Is the placeholder left around?
>
True, the placeholder sticks around in this case.  It wouldn't be hard
to track when a placeholder file is generated and remove it when it's
no longer needed.

Tracking the placeholder files would also be useful for namespace
collisions.  For example, if a Subversion repository adds a .gitignore
file to a previously committed empty directory.  The Subversion add
would need to be translated into a Git modification.  I'm not sure how
to store this information in the long-term tracking case, though.

> 3. I believe that this feature would be useful to people who are
> tracking a Subversion repository over time (not just for full
> migrations).  What happens if the user sometimes uses the new options
> and sometimes not?  Are the missing directories that have "accumulated"
> since the last invocation with --preserve-empty-dirs all added in the
> first commit resulting from a later use of --preserve-empty-directories,
> or are they skipped forever?  I'm talking about this scenario:
>
> Subversion                   git
> ----------                   ---
> Add empty directory "a"
>                             git svn fetch --preserve-empty-dirs
> Add empty directory "b"
>                             git svn fetch
> Add empty directory "c"
>                             git svn fetch --preserve-empty-dirs
>
> After the third "git svn fetch", does the git repository contain
> directory "b"?
>
In this case, the git repository would not contain the "b" directory,
but it would exist in the user's working copy without a placeholder
file.  I can only think of two situations when this is inappropriate.
First, if the user checks out earlier revisions, the empty directories
would persist.  Second, if anybody clones the Git repository, they'd
be missing the empty directories.

How problematic are these two cases?  I think re-fetching everything
from the Subversion repository is the only way to fix this.

If support for long-term tracking is deemed desirable, then maybe this
feature should be on by default.  Otherwise, you increase the chance
that repository data will be irrevocably damaged.

- Ray

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories
  2011-05-18  8:33   ` Eric Wong
  2011-05-18  9:14     ` Michael J Gruber
@ 2011-05-18 10:59     ` Ray Chen
  2011-05-18 20:01       ` Eric Wong
  2011-05-19  3:11     ` Michael Haggerty
  2 siblings, 1 reply; 11+ messages in thread
From: Ray Chen @ 2011-05-18 10:59 UTC (permalink / raw)
  To: Eric Wong; +Cc: Michael Haggerty, git

On Wed, May 18, 2011 at 4:33 AM, Eric Wong <normalperson@yhbt.net> wrote:
>
>> 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...
>
I'm not sure what you mean by this.  Do you mean that options
shouldn't be settable both on the command line and the config file?  I
think this situation already exists with the --no-metadata option.

>
>> 6. Documentation patches would also be required.
>
> Agreed, along with automated test cases.
>
No problem.  Might take a while, though.  I haven't looked at the test
case system yet.

- Ray

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories
  2011-05-18  9:14     ` Michael J Gruber
@ 2011-05-18 11:10       ` Ray Chen
  0 siblings, 0 replies; 11+ messages in thread
From: Ray Chen @ 2011-05-18 11:10 UTC (permalink / raw)
  To: Michael J Gruber; +Cc: Eric Wong, Michael Haggerty, git

On Wed, May 18, 2011 at 5:14 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
>>
>> 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.
>

I'll let people more experienced than I come to a conclusion on this one.

I can say I'm loath to spend a lot of time on this, given that it
might all be replaced within two months by Dmitry Ivankov's GSoC
project.

- Ray

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories
  2011-05-18 10:59     ` Ray Chen
@ 2011-05-18 20:01       ` Eric Wong
  0 siblings, 0 replies; 11+ messages in thread
From: Eric Wong @ 2011-05-18 20:01 UTC (permalink / raw)
  To: Ray Chen; +Cc: Michael Haggerty, git

Ray Chen <rchen@cs.umd.edu> wrote:
> On Wed, May 18, 2011 at 4:33 AM, Eric Wong <normalperson@yhbt.net> wrote:
> >
> >> 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...
> >
> I'm not sure what you mean by this.  Do you mean that options
> shouldn't be settable both on the command line and the config file?  I
> think this situation already exists with the --no-metadata option.

git-svn automatically understands configuration options based on the
command-line options (see sub read_get_config).

-- 
Eric Wong

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories
  2011-05-18  8:33   ` Eric Wong
  2011-05-18  9:14     ` Michael J Gruber
  2011-05-18 10:59     ` Ray Chen
@ 2011-05-19  3:11     ` Michael Haggerty
  2 siblings, 0 replies; 11+ messages in thread
From: Michael Haggerty @ 2011-05-19  3:11 UTC (permalink / raw)
  To: Eric Wong; +Cc: Ray Chen, git

On 05/18/2011 10:33 AM, Eric Wong wrote:
> Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> 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 agree that the checkin should not be done automatically.  But it is
exactly to assist the explicit (manual) maintenance of placeholder files
in Subversion that this feature could be useful.

> 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.

Indeed, by default git-svn should leave no trace.  But there are other
workplaces (mine included) where the use of git-svn is welcomed and
supported.  For us, features like "git svn create-ignore" are used to
maintain .gitignore files that are committed to Subversion.  Perhaps
there needs to be a repository-wide flag to distinguish between:

"conversion mode" -- This mode would be intended for full conversions to
git.  Placeholders created for empty directories, svn:ignore properties
converted automatically into .gitignore files, etc.  These actions would
happen automatically whenever a Subversion commit is retrieved and the
changes would be added to the git history as if they had happened in the
corresponding SVN commit.  "git svn dcommit" would be forbidden from
such repositories.

"working mode" -- This mode would support the use of git-svn as a
front-end to Subversion.  It would never push git-related changes to
Subversion except at the explicit request of the user.  In this mode,
there would be commands (like "git svn create-ignore") to create git
aids like placeholders and .gitignore files in the working copy, but
only at the explicit request of the user, and these changes would never
be committed automatically.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories
  2011-05-17 22:00 [PATCH/RFC] git-svn: New flag to add a file in empty directories Ray Chen
  2011-05-18  7:22 ` Michael Haggerty
  2011-05-18  8:22 ` Eric Wong
@ 2014-07-23  0:06 ` Gaffney
  2 siblings, 0 replies; 11+ messages in thread
From: Gaffney @ 2014-07-23  0:06 UTC (permalink / raw)
  To: git

Any idea why this parameter would slow down a clone so severely?  I am
experiencing clone slowdown by 5x+ after adding this parameter, which is not
cool given the size of the repository and the urgency of finishing the
migration.



--
View 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
Sent from the git mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2014-07-23  0:06 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-17 22:00 [PATCH/RFC] git-svn: New flag to add a file in empty directories Ray Chen
2011-05-18  7:22 ` Michael Haggerty
2011-05-18  8:33   ` Eric Wong
2011-05-18  9:14     ` Michael J Gruber
2011-05-18 11:10       ` Ray Chen
2011-05-18 10:59     ` Ray Chen
2011-05-18 20:01       ` Eric Wong
2011-05-19  3:11     ` Michael Haggerty
2011-05-18 10:46   ` Ray Chen
2011-05-18  8:22 ` Eric Wong
2014-07-23  0:06 ` Gaffney

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.