[sldev] Created page on source control
Paul TBBle Hampson
Paul.Hampson at Pobox.com
Wed Jun 20 06:34:07 PDT 2007
On Tue, Jun 19, 2007 at 09:09:56AM -0700, Dzonatas wrote:
> Paul TBBle Hampson wrote:
> >Having recently become enamoured of git, (and git-svn), I'd love to
> >
> Torvalds has recently lobbied git as ready for mainstream, but he also
> noted that it doesn't have all the nice front-end features of other
> SCMs. If git can be used with tools like TortiseSVN/TortiseMerge, or
> anything like that, it may be worthwhile to review.
Indeed. I'm hoping TortoiseGIT is ready in time for the next project at
work, since the size of the repositories we deal with makes an SVN
checkout unneccesarily expensive.
> The major difference is that the repository has to be broken up into
> git-projects unlike where everything is put together in svn, being
> only delineated by directories.
I don't understand what you mean by this...
If you're suggesting that SVN can have repos at both svn://server/bob
and svn://server/bob/subbranch, that's actually a rather painful way of
dealing with repositories, I think.
If you're talking about being able to have branches named things like
/branches/bob/beaver/firsttry, that turns out to still be a rather
difficult way of dealing with things.
I like that git has pulled branches and tags back out of the directory
namespace, while keeping branching as cheap or cheaper than svn, with
the added bonus of being able to throw away branches trivially.
For example, my git-svn workflow involves frequent calls of:
git-commit -m Shelf -a && git-svn rebase && git-reset HEAD^
which is neccessary because git-svn's rebase requires a clean
tree, with nothing uncomitted, and this puts me back where I was
before the rebase.
This is the equivalent of svn update, except that it can merge files
I've added with identical content, rather than aborting the update and
complaining to me.
> Torvalds tends to compare svn to cvs in the sense of a linear
> repository, which cvs is a major restriction of cvs. He doesn't seem
> to make any comparison to a svn repository that is setup more to a
> deep tree structure. You can easily recognized the branch level in
> svn. Most svn users still have their repository setup in a linear
> fashion with one branch level, being one branch directory with lots of
> version directories stuck under that one branch directory. The power
> of git can be still simulated in a svn-repository with the deeper tree
> structure, where you have branches that spawn more branch directories
> and each sub-branch level feeds into the super-branch level. At that
> point, git only does it in a more distributed fashion.
The issues Linus raises with svn and cvs aren't to do with the
namespace, but to do with the fundamentals of branching, merging and
distribution.
I would _love_ to be able to say to a non-programmer who's assets
I'm programming for "Please pull <URL> and see if it works" rather
than either comitting the code untested, getting the assets and
committing them from my tree, pulling the assets into my working
copy, testing the code and then purging the assets so the final assets
don't conflict with them, or any other variation that SVN currently
enforces upon me.
The pain of a 'switch' against a large SVN repository, even if most
files aren't changing, compounds upon the fact that if the
non-programmer is dealing with assets that two different code branches
use, it may be impossible to switch to something that'll allow testing.
We've basically come to the conclusion that 'no branching' is the rule,
at least for the projects that have to be in the always-usable state.
I am looking forward to the subprojects support in git becoming more
integrated in the porcelins, since juggling upstream source is a source
of concern, which SVN externals have made roughly bearable.
--
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson at Pobox.com
Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
-- Kristian Wilson, Nintendo, Inc, 1989
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070620/4a7f6877/attachment-0001.pgp
More information about the SLDev
mailing list