On Wed, 3 Apr 2019, Eric Johnson wrote:
> > The most obvious alternative that I can think of is to use "git-svn".
> > Instead of pushing changes to Subversion, push them to Git. Keep changes in
> > Git in sync with the main Subversion repository.
> >
> > Whenever you're ready, push changes from Git back to Subversion.
> >
> > Eric.
>
>
> Unfortunately, it means that nobody touches the repository between 1 and 6....
>
> I think the git-svn approach is likely to be the most successful strategy.
>
> Eric.
Since I'm also a mercurial fan I figured I'd put a plug in for:
https://bitbucket.org/durin42/hgsubversion/overview/
Mercurial might have a more friendly commandline for someone familiar with svn anyway.
I asked durin42 in irc://irc.freenode.net/mercurial just for the heck of it and he said:
14:55 <@durin42> nemo: last I knew hgsubversion is substanially more paranoid.
14:55 < nemo> durin42: hm. is that good or bad ☺
14:55 <@durin42> nemo: (I'm sure I've previously used hgsubversion to splice svn histories together)
14:56 <@durin42> nemo: it's good: the paranoia means it doesn't "handle" as many repositories, but it means it's less likely to ninja-lose some data.
14:57 < nemo> durin42: I thought maybe "real" branches and such would be more helpful, but I guess it depends... since svn branches are just folders, maybe you'd be better off using hg cp in a situation like this anyway
14:58 <@durin42> well you could put hgsubversion in single-directory mode and clone the parent dir of trunk
14:58 <@durin42> and it'd probably do a pretty decent job
14:58 < nemo> huh. never heard of "single directory mode"
14:59 <@durin42> typically you use hgsubversion in automatic mode, where it sniffs for {branches,tags,trunk} and tries to do the Right Thing
14:59 <@durin42> This logic is, it seems, good enough you're blissfully unaware of it.
Just FWIW ☺
Received on 2019-04-03 22:26:55 CEST