Comments on: Git-SVN: Using Git to Interact with Subversion Repositories http://fnd.lewcid.org/blog/archive/21 Just Another Personal Wobsite Wed, 07 Oct 2009 10:30:35 +0000 hourly 1 http://wordpress.org/?v=3.0 By: » Git Basics: Getting Started FND’s Blag: Just Another Personal Wobsite http://fnd.lewcid.org/blog/archive/21/comment-page-1#comment-4275 » Git Basics: Getting Started FND’s Blag: Just Another Personal Wobsite Sat, 28 Mar 2009 10:43:06 +0000 http://fnd.lewcid.org/blog/?p=21#comment-4275 [...] Published in March 28th, 2009 Posted by FND Tags: development, Git, revision control Since my last post on the subject, I’ve become much more familiar and comfortable with [...] [...] Published in March 28th, 2009 Posted by FND Tags: development, Git, revision control Since my last post on the subject, I’ve become much more familiar and comfortable with [...]

]]> By: HeX http://fnd.lewcid.org/blog/archive/21/comment-page-1#comment-978 HeX Sat, 24 May 2008 12:13:29 +0000 http://fnd.lewcid.org/blog/?p=21#comment-978 >> why not switching to GIT completely with > dev.tiddlywiki.org > > Apart from the fact that changing an existing (and > proven) system is always a hassle, switching to Git > would probably scare off a lot of (potential) > developers. It’s hard enough getting people to use > SVN… (Although for someone who has never used a VCS > before, learning Git is probably not any harder than > getting used to SVN.) Yes I wasn't really serious here as I also experiencing exactly the same "arguments" in my working environment. Once svn 1.5 is out which finally can remember the history of a merged branch (so I was told) it's probably not all that bad anyway (well there still is the repo size, the network dependency, and the speed...) Also, I was very much tempted to go for Bazaar (well Ubuntu is using it for launchpad so it should be pretty good) but I couldn't get used to the workflow that every branch created resides in a separate directory in your workspace and has to stay there if you want to work with that branch. >> there is a Trac plugin available > > I’ve heard of that, but haven’t seen it in action yet. Have a look at the project page. There are some example pages given that use that plugin. >> why not switching to GIT completely with
> dev.tiddlywiki.org
>
> Apart from the fact that changing an existing (and
> proven) system is always a hassle, switching to Git
> would probably scare off a lot of (potential)
> developers. It’s hard enough getting people to use
> SVN… (Although for someone who has never used a VCS
> before, learning Git is probably not any harder than
> getting used to SVN.)

Yes I wasn’t really serious here as I also experiencing exactly the same “arguments” in my working environment. Once svn 1.5 is out which finally can remember the history of a merged branch (so I was told) it’s probably not all that bad anyway (well there still is the repo size, the network dependency, and the speed…)

Also, I was very much tempted to go for Bazaar (well Ubuntu is using it for launchpad so it should be pretty good) but I couldn’t get used to the workflow that every branch created resides in a separate directory in your workspace and has to stay there if you want to work with that branch.

>> there is a Trac plugin available
>
> I’ve heard of that, but haven’t seen it in action yet.

Have a look at the project page. There are some example pages given that use that plugin.

]]> By: FND http://fnd.lewcid.org/blog/archive/21/comment-page-1#comment-976 FND Sat, 24 May 2008 10:08:35 +0000 http://fnd.lewcid.org/blog/?p=21#comment-976 Thanks HeX! > I would be careful with the '--squash' option though. > Since this means the commit history of the svn repo only > contains a (maybe) huge junk of changes within one > commit. You do have a point there. However, I'm actively trying to avoid that my local Git usage results in less frequent (and thus more opaque) commits to the public repo. IMO, a public commit should form a meaningful and coherent unit — which the individual local commits often don't. So once I've got such a chunk ready, I push it to SVN (see <a href="http://trac.tiddlywiki.org/timeline" rel="nofollow">TiddlyWiki timeline</a>). > You even might consider squashing only some of the > commits together. The '--interactive' option is a great > tool for this. I'll definitely look into that. > highlight shortly how 'git-svn dcommit' works You just did — thanks for that! (I didn't wanna bloat the post with too many details.) > As for your last step of all the single commits (switching > back to your WIP branch) there is really no alternative Good to know I wasn't completely off. I'll change that step to use merge soon (need to try it myself first). > why not switching to GIT completely with dev.tiddlywiki.org Apart from the fact that changing an existing (and proven) system is always a hassle, switching to Git would probably <a href="http://groups.google.com/group/TiddlyWikiDev/browse_thread/thread/5ee2ab739ac825d3/bd92f87e66f71d08#bd92f87e66f71d08">scare off</a> a lot of (potential) developers. It's hard enough getting people to use SVN... (Although for someone who has never used a VCS before, learning Git is probably not any harder than getting used to SVN.) > there is a Trac plugin available I've heard of that, but haven't seen it in action yet. Thanks HeX!

> I would be careful with the ‘–squash’ option though.
> Since this means the commit history of the svn repo only
> contains a (maybe) huge junk of changes within one
> commit.

You do have a point there.
However, I’m actively trying to avoid that my local Git usage results in less frequent (and thus more opaque) commits to the public repo.
IMO, a public commit should form a meaningful and coherent unit — which the individual local commits often don’t. So once I’ve got such a chunk ready, I push it to SVN (see TiddlyWiki timeline).

> You even might consider squashing only some of the
> commits together. The ‘–interactive’ option is a great
> tool for this.

I’ll definitely look into that.

> highlight shortly how ‘git-svn dcommit’ works

You just did — thanks for that! (I didn’t wanna bloat the post with too many details.)

> As for your last step of all the single commits (switching
> back to your WIP branch) there is really no alternative

Good to know I wasn’t completely off.
I’ll change that step to use merge soon (need to try it myself first).

> why not switching to GIT completely with dev.tiddlywiki.org

Apart from the fact that changing an existing (and proven) system is always a hassle, switching to Git would probably scare off a lot of (potential) developers. It’s hard enough getting people to use SVN… (Although for someone who has never used a VCS before, learning Git is probably not any harder than getting used to SVN.)

> there is a Trac plugin available

I’ve heard of that, but haven’t seen it in action yet.

]]> By: HeX http://fnd.lewcid.org/blog/archive/21/comment-page-1#comment-975 HeX Sat, 24 May 2008 09:37:51 +0000 http://fnd.lewcid.org/blog/?p=21#comment-975 Nice summary, I would be careful with the '--squash' option though. Since this means the commit history of the svn repo only contains a (maybe) huge junk of changes within one commit. I think there is probably no harm to let your colleagues who haven't seen the light yet (i.e. still using svn) to know which discrete steps led to your awesome new piece of code (and in case it wasn't all that awesome might help them debugging it by following your multiple commits instead of a huge one). But that's up to you. You even might consider squashing only some of the commits together. The '--interactive' option is a great tool for this. Perhaps you might also highlight shortly how 'git-svn dcommit' works (i.e. first pushes all your commits from your repo up to the svn repo one by one and *then* does a rebase so that the time line of the svn repo and your git repo are in sync). As for your last step of all the single commits (switching back to your WIP branch) there is really no alternative other than: a) git-svn rebase b) git merge master 'b)' being probably much faster and can be done locally as no network connection is required And last but not least...there is a Trac plugin available http://trac-hacks.org/wiki/GitPlugin. So why not switching to GIT completely with dev.tiddlywiki.org ;) (Yes I know the learning curve for new users *seems* to be quite steep and handling of sub-modules is also not the easiest to get your head round) Nice summary,
I would be careful with the ‘–squash’ option though. Since this means the commit history of the svn repo only contains a (maybe) huge junk of changes within one commit. I think there is probably no harm to let your colleagues who haven’t seen the light yet (i.e. still using svn) to know which discrete steps led to your awesome new piece of code (and in case it wasn’t all that awesome might help them debugging it by following your multiple commits instead of a huge one). But that’s up to you. You even might consider squashing only some of the commits together. The ‘–interactive’ option is a great tool for this.

Perhaps you might also highlight shortly how ‘git-svn dcommit’ works (i.e. first pushes all your commits from your repo up to the svn repo one by one and *then* does a rebase so that the time line of the svn repo and your git repo are in sync).

As for your last step of all the single commits (switching back to your WIP branch) there is really no alternative other than:
a) git-svn rebase
b) git merge master
‘b)’ being probably much faster and can be done locally as no network connection is required

And last but not least…there is a Trac plugin available http://trac-hacks.org/wiki/GitPlugin. So why not switching to GIT completely with dev.tiddlywiki.org ;) (Yes I know the learning curve for new users *seems* to be quite steep and handling of sub-modules is also not the easiest to get your head round)

]]>