From: Andrew Sayers <andrew-git@pileofstuff.org>
To: Florian Achleitner <florian.achleitner2.6.31@gmail.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
Ramkumar Ramachandra <artagnon@gmail.com>,
David Barr <davidbarr@google.com>,
Sverre Rabbelier <srabbelier@gmail.com>,
Dmitry Ivankov <divanorama@gmail.com>
Subject: Re: GSOC Proposal draft: git-remote-svn
Date: Sat, 14 Apr 2012 22:35:59 +0100 [thread overview]
Message-ID: <4F89EDBF.9050906@pileofstuff.org> (raw)
In-Reply-To: <1472353.TRfidGPc01@flomedio>
On a slightly different topic, here's the only branching edge case I
know of that will affect you. I agree with Jonathan that you should
focus on the standard layout for now, but I think it's worth having the
trickier cases in your head when you're planning things out.
Imagine a team does this:
# Slight misunderstanding of the standard layout at first:
mkdir trunk/project1 trunk/project2
svn add trunk
svn ci -m "Initial revsion" # r1
# Time passes, commits are made, people get smarter.
# In revision 1000, the team decides to put the structure right:
svn rm trunk
svn ci -m "Removed incorrect directory name" # r1000
mkdir trunk
touch trunk/MOVED_TO_PROJECT_TRUNK
svn ci -m "Added signpost file for future reference" # r1001
mkdir project1 project2
svn cp -r 999 trunk/project1 project1/trunk
svn cp -r 999 trunk/project2 project2/trunk
svn ci -m "Recreated projects with correct directory names" # r1002
This would be represented in SBL something like:
In r1, create branch "trunk/project1"
In r1, create branch "trunk/project2"
# We would prefer just to deactivate these...
In r1000, deactivate "trunk/project1"
In r1000, deactivate "trunk/project2"
# ... but we have to delete them,
# because git doesn't support recursive branch names:
In r1001, delete branch "trunk/project1"
In r1001, delete branch "trunk/project2"
In r1001, create branch "trunk"
# We deleted the branches, so how do we get the commit to fork from?
In r1002, create branch "project1/trunk" from "trunk/project1" r999
In r1002, create branch "project2/trunk" from "trunk/project2" r999
If you look in your ".git/refs/heads/" directory, you'll see git
branches are stored as files on disk. So if you have a branch
"trunk/project1", you can't create a branch called "trunk" unless you
delete the directory called "trunk" first. This unfortunate limitation
of an otherwise neat solution means you can't reliably use git branches
when retrieving older revisions.
Other people will be able to tell you if there's any interest in
removing this limitation, but even if there is, users will occasionally
change their mind after asking for a branch to be deleted, and be
surprised if SVN lets them but git doesn't.
One solution you could look at would be storing dead branches in a JSON
file somewhere. If you go down that route, remember that `git gc` will
try to garbage collect the commits once the branches have been dead for
long enough.
- Andrew
next prev parent reply other threads:[~2012-04-14 21:36 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-19 14:42 GSoC intro Florian Achleitner
2012-03-19 21:31 ` Andrew Sayers
2012-03-20 12:25 ` Florian Achleitner
2012-03-20 13:19 ` David Barr
2012-03-21 21:16 ` Florian Achleitner
2012-03-26 11:06 ` Ramkumar Ramachandra
2012-03-27 13:53 ` Florian Achleitner
2012-04-02 8:30 ` GSOC Proposal draft: git-remote-svn Florian Achleitner
2012-04-02 11:00 ` Ramkumar Ramachandra
2012-04-02 20:57 ` Jonathan Nieder
2012-04-02 23:04 ` Jonathan Nieder
2012-04-03 7:49 ` Florian Achleitner
2012-04-03 18:48 ` Jonathan Nieder
2012-04-05 16:18 ` Tomas Carnecky
2012-04-02 22:17 ` Andrew Sayers
2012-04-02 22:29 ` Jonathan Nieder
2012-04-02 23:20 ` Andrew Sayers
2012-04-03 0:09 ` Jonathan Nieder
2012-04-03 21:53 ` Andrew Sayers
2012-04-03 22:21 ` Jonathan Nieder
2012-04-05 13:36 ` Florian Achleitner
2012-04-05 15:47 ` Dmitry Ivankov
2012-04-09 18:59 ` Stephen Bash
2012-04-10 17:17 ` Jonathan Nieder
2012-04-10 22:30 ` Andrew Sayers
2012-04-10 23:46 ` Jonathan Nieder
2012-04-11 19:09 ` Florian Achleitner
2012-04-14 22:57 ` Andrew Sayers
2012-04-11 15:51 ` Jakub Narebski
2012-04-11 15:56 ` Jonathan Nieder
2012-04-11 19:20 ` Florian Achleitner
2012-04-11 19:44 ` Dmitry Ivankov
2012-04-11 19:53 ` Jonathan Nieder
2012-04-11 22:43 ` Andrew Sayers
2012-04-12 9:02 ` Thomas Rast
2012-04-12 15:28 ` Florian Achleitner
2012-04-12 22:30 ` Andrew Sayers
2012-04-14 20:09 ` Florian Achleitner
2012-04-14 21:35 ` Andrew Sayers [this message]
2012-04-15 3:13 ` Stephen Bash
2012-04-13 19:19 ` Jonathan Nieder
2012-04-14 20:15 ` Florian Achleitner
2012-04-18 20:16 ` Florian Achleitner
2012-04-19 12:26 ` Florian Achleitner
2012-03-28 8:09 ` GSoC intro Miles Bader
2012-03-28 9:30 ` Dmitry Ivankov
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=4F89EDBF.9050906@pileofstuff.org \
--to=andrew-git@pileofstuff.org \
--cc=artagnon@gmail.com \
--cc=davidbarr@google.com \
--cc=divanorama@gmail.com \
--cc=florian.achleitner2.6.31@gmail.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=srabbelier@gmail.com \
/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).