Re: [MONKEY PATCH] git-svn: allow two branch configurations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I tried this patch over the weekend, and it worked perfectly.

I've imported the head/, releng/, and stable/ FreeBSD branches, plus the release/ tags -- some 190,000 svn revisions.  The git repository is 720MB, compared to 4.6GB for the synsync'd mirror of the svn repo.

Michael J Gruber wrote:

I see two viable options for a real patch now:
- Extend $remote->branches to be an array and use "config --get-all" to
  read the config; do the same for tags.
- Use one single array for branches as well as tags.

Eric, which way do you prefer? The first one is simpler and may be even
doable for me. The second looks more complicated mainly because of "git
svn branch -t" (which element of the combined array is tags?), even
though it's more natural if one thinks about the way svn works.

I favor the first option, mainly because of its simplicity and because it seems natural to me to keep branches and tags separate, despite svn's mechanics.

With this capability, the 'git svn branch' command (and 'git svn tag') would need to be extended to allow the user to specify the location of the new branch (or tag).  I suggest a -d (for "destination") argument.  -d would be required if there's more than one branches (or tags, if -t is also specified) config option for the svn-remote.  The -d value must successfully glob against the LHS of one of the branches' (or tags') refspecs.

Thanks, Michael!  I'm going to start putting together some unit tests for this while the implementation details get sorted out.

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]