Re: Any technical reason why hgsubversion can't act as a svn bridge?

On Dec 2, 8:00 pm, Augie Fackler <duri...@...> wrote:
> On Dec 2, 2010, at 4:32 AM, Piet Skiet wrote:
>
> > Hi,
>
> > I'd like to follow this workflow at work:http://community.thoughtworks.com/posts/6e49c1e7b8
> > i.e. have a hg "gateway" into the svn server. According to the article
> > this is possible with git-svn. Are there any technical reasons why
> > hgsubversion can't be made to act this way. I know fom experience that
> > this doesn't work (merges prior to rebasing screws everything up for
> > the leaf committers).
>
> You'd have to write patches to hgsubversion that'd handle the bookkeeping, and know that you'd have to
back up some sort of revision equivalence database, as without that you'd be unable to continue staying in
sync. The basic workflow would be a push without a rebase. In the event that a new revision comes back when
you look for the revision you just pushed, those new revision(s) would be committed on top of their correct
parent revs and then a dummy merge would be created whose tree state was exactly the data pulled from
subversion for the pushed rev. That's probably confusing. If it is, ask and I'll try to diagram it out. Note
that this is all theoretical, and I don't personally have time to implement the feature.
>
> There's also the difficulty of usernames - you'll lose your authorship information when revisions go
back into svn.
>
>
>
> > Currently I have a workaround where I have both a subversion and hg
> > working copy in the same directory at the "gateway", and I manually
> > merge between svn and hg.
>
> > Best regards
>
> > --
> > You received this message because you are subscribed to the Google Groups "hgsubversion" group.
> > To post to this group, send email to hgsubversion@...
> > To unsubscribe from this group, send email to hgsubversion+unsubscribe <at> googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/hgsubversion?hl=en.

You're right, it is confusing, but then again I'm new to DVCS. Is the
approach you described above used by git-svn as well? I guess what I'd
like to know is if git-svn model is more suitable for svn bridging.

In the long run I'd like to convert the natives to a native Mercurial
setup, mainly because of the ease of distributed cross-platform use.

--

-- 
You received this message because you are subscribed to the Google Groups "hgsubversion" group.
To post to this group, send email to hgsubversion@...
To unsubscribe from this group, send email to hgsubversion+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hgsubversion?hl=en.