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 ☺
