Skip to main content

Diigo Home
Home/ Groups/ learning-git
Rss Feed
Sort By: Most Recent | Popular Filter: All | Bookmarks | Topics Simple Middle
Daniel Jomphe

D.C.T.W.Y.C.D.T: dancing between github and subversion repository - 0 views

ariya.blogspot.com/...een-github-and-subversion.html

git git-svn svn learning

shared by Daniel Jomphe on 01 Oct 08 - Snapshot
  • Once they send patches to you or push their branches, you can do the merge into your git repository and push it to github. Due to the said cron job, the subversion repository (e.g. in Google Code) will get the changes as well. Every now and then, when other contributors commit some changes to the subversion repository, the changes will be also propagated to github. Both parties are happy.
Daniel Jomphe

An introduction to git-svn for Subversion/SVK users and deserters - 0 views

utsl.gen.nz/...intro.html

bazaar comparison dvcs git mercurial svn vcs learning

shared by Daniel Jomphe on 01 Oct 08 - Snapshot
  • This article is aimed at people who want to contribute to projects
    which are using Subversion as their code-wiki
  • Subversion users can skip SVK and move straight onto
    git-svn with this tutorial.
  • People who are responsible for Subversion servers and are
    converting them to git in order to lay them down to die are
    advised to consider the one-off git-svnimport, which is
    useful for bespoke conversions where you don't necessarily want to
    leave SVN/CVS/etc breadcrumbs behind. I'll mention bespoke
    conversions at the end of the tutorial, and the sort of thing that
    you end up doing with them.
  • ...47 more annotations...
  • A lot of this tutorial is dedicated to advocacy, sadly necessary.
    Those who would rather just cut to the chase will probably want to
    skip straight to
  • Another way of looking at it is to say that it's really a content-
    addressable filesystem, used to track directory trees.
  • we've got a simple and efficient filesystem which
    competes with RevML but is XML free
  • Subversion added nothing to CVS' development model.
  • Yes, it's a
    bunch of small programs that do one thing and do it well, get over
    it, they're being unified
  • There's also a pure Java
  • I used to push strongly
    for SVK, but got brow-beaten by people who were getting far more out
    of their version control system than I knew possible until I saw
    what they were talking about.
  • SVK could easily use git as a
    backing filesystem and drop the dependency on Subversion altogether.
    So could bzr or hg.
  • The repository model (see right) is also simple enough that there are complete git re-implementations you can draw upon, in a variety of languages.
  • git is first and foremost a toolkit for writing VCS systems

  • Writing a tool to do something that you want is often quite a simple matter of plugging together a few core commands.

    It's simple enough that once a few basic concepts are there, you begin to feel comfortable knowing that the repository just can't wedge, changes can be discarded yet not lost unless you request them to be cleaned up, etc.

  • I really haven't seen a nicer tool than gitk for browsing a repository.
  • gitk does some really cool things but is most useful when looking at projects that have cottoned onto feature branches (see feature branches, below). If you're looking at a project where everyone commits largely unrelated changes to one branch it just ends up a straight line, and not very interesting.

  • You can easily publish your changes for others who are switched on to git to pull. At a stretch, you can just throw the .git directory on an HTTP server somewhere and publish the path.
  • There's the git-daemon for more efficient serving of repositories (at least, in terms of network use), and gitweb.cgi to provide a visualisation of a git repository.
  • With Subversion, everyone has to commit their changes back to the central wiki, I mean repository, to share them.
  • With Git (actually this is completely true for other distributed systems), it's trivial to push and pull changes between each other. If what you're pulling has common history then git will just pull the differences.
  • If the person publishes their repository as described above, using the git-daemon(1), http or anything else that you can get your kernel to map to its VFS, then you can set it up as a "remote" and pull from it
  • Most people say "but I don't want branches". But users of darcs report that they didn't know how much they really did want branches, but never knew until darcs made it so easy. In essence every change can behave as a branch, and this isn't painful.
  • Because you can easily separate your repositories into stable branches, temporary branches, etc, then you can easily set up programs that only let commits through if they meet criteria of your choosing.
  • Because you can readily work on branches without affecting the stable branch, it is perfectly acceptable for a stable branch to be updated by a single maintainer only
  • Some repositories, for instance the Linux kernel, run a policy of no commit may break the build. What this means is that if you have a problem, you can use bisection to work out which patch introduced the bug.
  • You might use a continual integration server that is responsible for promoting branches to trunk should they pass the strictures that you set.
  • There is an awful lot less to keep in your head, and you
    don't have to do things like plan branching in advance.
  • Good feature branches mean you end up prototyping
    well-developed changes    ; the emphasis shifts away from making
    atomic commits. If you forgot to add a file, or made some
    other little mistake, it's easy to go back and change it. If you
    haven't even pushed your changes anywhere, that's not only fine, but
    appreciated by everyone involved. Review and revise
    before you push     is the counter-balance to frequent commits.
  • Not only is the implementation fast locally, it's very network
    efficient, and the protocol for exchanging revisions is also very
    good at figuring out what needs to be transferred quickly. This is
    a huge difference - one repository hosted on Debian's Alioth SVN server took
    2 days to synchronise because the protocol is so chatty.
    Now it fits in 3 megs and would not take that long to synchronise
    over a 150 baud modem.

  • Disk might be cheap, but my /home is always full -
    git has a separate step for compacting repositories, which
    means that delta compression can be far more effective. If
    you're a compression buff, think of it as having an arbitrarily
    sized window, because when delta compressing git is able to match
    strings anywhere else in the repository - not just the file
    which is the notional ancestor of the new revision.

    This space efficiency affects everything - the virtual memory
    footprint in your buffercache while mining information from the
    repository, how much data needs to be transferred during "push" and
    "pull" operations, and so on. Compare that to Subversion, which
    even when merging between branches is incapable of using the same
    space for the changes hitting the target branch. The results speak
    for themselves - I have observed an average of 10 to 1
    space savings going from Subversion FSFS to git.

  • Perhaps somebody has already made a conversion of the project and put it somewhere
  • git-svn fetch
  • But people who use git are used to treating their repositories as a revision data warehouse which they use to mine useful information when they are trying to understand a codebase.
  • importing the whole repository from Subversion
  • git svn init
  • git svn fetch
  • If you like, you can skip early revisions using the -r
    option to git-fetch.
  • make a local branch for development
  • The name "foo" is completely private; it's just a local name you're assigning to the piece of work you're doing. Eventually you will learn to group related commits onto branches, called "topic branches", as described in the introduction.
  • Say you want to take a project, and work on it somewhere else in a different direction, you can just make a copy using cp or your favourite file manager. Contrast this with Subversion, where you have to fiddle around with branches/ paths, svn cp, svn switch, etc
  • Each of those copies is fully independent, and can diverge freely. You can easily push and pull changes between them without tearing your hair out.
  • Each time you have a new idea, make a new branch and work in that.
  • But anyway, that copying was too slow and heavy. We don't want to copy 70MB each time we want to work on a new idea. We want to create new branches at the drop of a hat. Maybe you don't want to copy the actual repository, just make another checkout. We can use git-clone again
  • The -l option to git-clone told git to hardlink the objects together, so not only are these two sharing the same repository but they can still be moved around independently. Cool. I now have two checkouts I can work with, build software in, etc.
  • But all that's a lot of work and most of the time I don't care to create lots of different directories for all my branches. I can just make a new branch and switch to it immediately with git-checkout:
  • Once you have some edits you want to commit, you can use git-commit to commit them. Nothing (not even file changes) gets committed by default; you'll probably find yourself using git-commit -a to get similar semantics to svn commit.
  • There is also a GUI for preparing commits in early (but entirely functional) stages of development.
  • People used to darcs or SVK's interactive commit will like to try git add -i
  • correcting changes in your local branch
  • If it's the top commit, you can just add --amend to your regular git-commit command to, well, amend the last commit. If you explored the git-gui interface, you might have noticed the "Amend Last Commit" switch as well.
1 - 20 of 61 Next › Last »
Showing 20▼ items per page
Join this group