Comments | unayok: DVCS

unayok

DVCS

Jun 07, 2009 16:36

I've just pushed the first commits to my newest (public) coding project: genosha (no apologies for the name at all ;> ). A pretty small one, but it's been kind of fun to do. While the other project I've opened up to all comers (terbium) has application for general computer users (despite its lack of point-and-droolness, it's actually reasonable ( Read more... )

genosha, terbium, coding, python

Comments 5

spiziks June 7 2009, 22:09:12 UTC

You are =such= a geek! :)

redwolfexr June 11 2009, 22:28:43 UTC

Glad to see it wasn't just me thinking that...

Software dudes sure make things complicated.

unayok June 12 2009, 00:04:26 UTC

No, we expose the underlying complexity that is already there.

I should get a t-shirt "CENTRAL SERVICES".

10 points if you get the reference.

theobviousname June 16 2009, 02:07:27 UTC

What makes SVN painful? We're still using CVS at work, but since that's almost exclusively mediated by the IDE (which supports multiple concurrent changesets, shelving changes, etc.) I only ever really bump into it when I'm delving into the history of a file and it breaks on file move or rename.

What's the difference between a VCS and a DVCS?

unayok June 16 2009, 02:49:30 UTC

Super ultra-short response: SVN is slow, it's unfun to deal with branches or anything other than the most trivial of merges (without external assistance). It requires fiddly set up of a master repository. It pollutes your project's directory structure with .svn (.cvs) dirs for tracking. It manages changes on a file by file basis rather than a project changeset basis (even though revision numbers are "global"). And it's slow. It doesn't differentiate between local editing and merges from other branches. Getting diffs between branches is ugly at best. You can't commit to a local repository and then deal with merges from an upstream repository; you *have* to slave your local repository to the ultimate master first ( ... )