From: Jakub Narebski <jnareb@gmail.com>
To: mrevilgnome <mrevilgnome@gmail.com>
Cc: Will Palmer <wmpalmer@gmail.com>,
Ramkumar Ramachandra <artagnon@gmail.com>,
Stephen Bash <bash@genarts.com>,
git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
David Michael Barr <david.barr@cordelta.com>,
Sverre Rabbelier <srabbelier@gmail.com>,
Tomas Carnecky <tom@dbservice.com>
Subject: Re: Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch)
Date: Thu, 21 Oct 2010 10:16:46 +0200 [thread overview]
Message-ID: <201010211016.47998.jnareb@gmail.com> (raw)
In-Reply-To: <AANLkTi=mhN1M+KrGVCYLhZiMUMXSABG-YEPPgDFb-nSv@mail.gmail.com>
On Thu, 21 Oct 2010, mrevilgnome wrote:
> Jakub Narebski wrote:
> > Subversion uses the inter-file branching model (Wikipedia says it was
> > "borrowed" from Perforce) to handle branches and tags. It uses "branches
> > are copies (folders)" paradigm, and technically it doesn't have separate
> > namespace for branches but have projects, branches, and projects'
> > filesystem hierarchy mixed together; what part of path is branch name
> > is defined by convention only. This model makes it easy to mess up
> > repository (because there are no technological barriers for going
> > against conventions, like mentioned all-branches change, or changing
> > tags, or reversed hierarchy or branches and projects).
>
> I agree. The repository that I'm interested in converting has
> branches all over the place /sandbox/, /sandbox/<username>/*,
> /stable/MAIN/*, /stable/Features/*, /features/*, /branches/*, etc...
> Because subversion didn't enforce the convention it was all to easy to
> ignore when our questionable branching strategy was created. Instead
> of expecting sub-folders of a particular path to be a branch is there
> something that we can key off of in the dumpfile? Are copy operations
> notated in some fashion?
Actually it shouldn't be that hard to implement, it it isn't already
implemented in svn-fe.
We don't need to have copy operations notated in some fashion; it should
be enough to tell svn-fe where the top directory of project is in
repository tree hierarchy (e.g. that it is at /stable/MAIN/* at
revision 1). git-fe can/could use then 'tree' movement detection that
'subtree' merge strategy uses.
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2010-10-21 8:17 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-13 15:44 Speeding up the initial git-svn fetch Matt Stump
2010-10-13 16:02 ` Stephen Bash
2010-10-13 17:47 ` Matt Stump
2010-10-13 18:18 ` Stephen Bash
2010-10-14 16:22 ` Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch) Stephen Bash
2010-10-14 16:34 ` Jonathan Nieder
2010-10-14 20:07 ` Sverre Rabbelier
2010-10-15 14:50 ` Stephen Bash
2010-10-15 23:39 ` Sverre Rabbelier
2010-10-16 0:16 ` Stephen Bash
2010-10-17 2:25 ` Sverre Rabbelier
2010-10-17 3:33 ` David Michael Barr
2010-10-18 5:17 ` Ramkumar Ramachandra
2010-10-18 7:31 ` Jonathan Nieder
2010-10-18 16:38 ` Ramkumar Ramachandra
2010-10-18 16:46 ` Sverre Rabbelier
2010-10-18 16:56 ` Jonathan Nieder
2010-10-18 17:16 ` Ramkumar Ramachandra
2010-10-18 17:18 ` Sverre Rabbelier
2010-10-18 17:28 ` Jonathan Nieder
2010-10-18 18:10 ` Sverre Rabbelier
2010-10-18 18:13 ` Jonathan Nieder
2010-10-18 18:20 ` Sverre Rabbelier
2010-10-18 18:25 ` Jonathan Nieder
2010-10-18 18:35 ` Sverre Rabbelier
2010-10-18 19:33 ` Jonathan Nieder
2010-10-19 3:08 ` Ramkumar Ramachandra
2010-10-19 0:40 ` Stephen Bash
2010-10-19 1:42 ` Stephen Bash
2010-10-19 6:42 ` Ramkumar Ramachandra
2010-10-19 13:33 ` Stephen Bash
2010-10-19 14:28 ` David Michael Barr
2010-10-19 14:57 ` Stephen Bash
2010-10-20 8:39 ` Will Palmer
2010-10-20 11:59 ` Jakub Narebski
2010-10-20 13:42 ` Will Palmer
2010-10-20 20:44 ` Jakub Narebski
2010-10-21 1:54 ` mrevilgnome
2010-10-21 8:16 ` Jakub Narebski [this message]
2010-10-21 13:49 ` Stephen Bash
2010-10-21 9:08 ` Will Palmer
2010-10-21 14:00 ` Stephen Bash
2010-10-21 18:37 ` Jakub Narebski
2010-10-21 21:27 ` Stephen Bash
2010-10-21 22:49 ` Jakub Narebski
2010-10-21 23:26 ` Stephen Bash
2010-10-22 10:38 ` Jakub Narebski
2010-10-21 15:52 ` Jakub Narebski
2010-10-21 16:16 ` Jonathan Nieder
2010-10-20 14:05 ` Ramkumar Ramachandra
2010-10-20 14:21 ` Stephen Bash
2010-10-20 16:56 ` Ramkumar Ramachandra
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=201010211016.47998.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=artagnon@gmail.com \
--cc=bash@genarts.com \
--cc=david.barr@cordelta.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=mrevilgnome@gmail.com \
--cc=srabbelier@gmail.com \
--cc=tom@dbservice.com \
--cc=wmpalmer@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 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.