Thread (31 messages) flat view 31 messages, 2 authors, 2016-06-15

Re: Trying to sync two svn repositories with git-svn (repost)

From: Josef Wolf <hidden>
Date: 2016-06-15 22:46:48

On Fri, May 15, 2009 at 03:05:14PM -0400, Avery Pennarun wrote:
On Fri, May 15, 2009 at 1:52 PM, Josef Wolf [off-list ref] wrote:
quoted
On Thu, May 14, 2009 at 05:57:00PM -0400, Avery Pennarun wrote:
quoted
I'd say that basically none of your problems have anything to do with
svn's lack of merge support, and everything to do with the fact that
you aren't doing all your changes first on a 'public' branch and then
merging from there into the private branches.  (That's really not so
hard to do in svn either, and would save a ton of confusion.)
The problem here is that it does not match the work flow.  IMHO, my work
flow is very similar to the work flow of the kernel, so I fail to see why
it can not work.  See the analogies:

kernel: Submodule maintainers are committing into private repositories
me:     People are committing into private repositories

kernel: Those commits are forwarded to Linus's repository
me:     Those commits are forwarded to the public repository

kernel: Maintainers receive commits for other submodules from linus
me:     Commits are distributed from public to private repositories
There is one critical difference here: if someone merges from Linus
and then Linus merges back from them, then the two resulting
repositories will be *identical* (at least, the trees will be; if the
second merge uses --no-ff, the histories will be very slightly
different, but not importantly so).
Hmm, maybe submodules could be of some help here?  If I put the generic
content into a submodule, and the localized content into (multiple)
superprojects, the kernel work flow should be easy to adopt, or am I
missing something?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help