git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Ray Chen <rchen@cs.umd.edu>
Cc: git@vger.kernel.org, Eric Wong <normalperson@yhbt.net>
Subject: Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories
Date: Wed, 18 May 2011 09:22:53 +0200	[thread overview]
Message-ID: <4DD373CD.6010607@alum.mit.edu> (raw)
In-Reply-To: <1305669635-10861-1-git-send-email-rchen@cs.umd.edu>

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/

  reply	other threads:[~2011-05-18  7:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

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

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

  git send-email \
    --in-reply-to=4DD373CD.6010607@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git@vger.kernel.org \
    --cc=normalperson@yhbt.net \
    --cc=rchen@cs.umd.edu \
    /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.
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 NNTP newsgroup(s).