[CPLUG] Dual-boot Linux

Spencer Ellsworth sellswor at calpoly.edu
Tue Jan 13 07:24:19 PST 2009


Hi again,
Thank you all so much for these responses, they have been quite helpful.
Back toward the beginning of this email chain, someone mentioned putting a
linked folder on my personal desktop leading to my files on Vogon/the
CalPoly server, so that any work I did on my personal machine could be saved
there. How complicated is it to set something like this up? Can some one run
through the instructions briefly for me? I would greatly appreciate it.

~Spencer

On Tue, Jan 13, 2009 at 12:59 AM, David Sharp <whereami at gmail.com> wrote:

> On Mon, Jan 12, 2009 at 11:06 PM, Mark Gius <mgius7096 at gmail.com> wrote:
> > The problem I have with git on school machines is that since you're
> > making all of your commits locally, if you don't for whatever reason
> > push to an external server and vogon goes down (a frequent occurrence),
> > you've just lost your work.
>
> You're stretching it...
>
> 1) all git repositories have a complete history of the code. There are
> FEWER points of failure if you replicate even just once.
> 1a) git commit IDs are cryptographic hashes of the commit's history
> and content. With svn, you may never know if your repository has been
> corrupted. Your data are MORE secure with git.
> 2) you can go use your other copy of the repository to continue
> working on another part of the code, and when vogon comes back, you
> can merge. And with git, it is easy and normal to merge, as opposed to
> SVN where merging may take you all day.
> 3) Why would you forget to push, anyway? forgetting to push is like
> forgetting to commit. It becomes part of the process.
>
> > Since SVN doesn't allow local commits, all
> > of your changes are automatically synced to an external server without
> > any extra effort (assuming you have an external server to dump to).
>
> well, that's just not true. SVN does allow commits over the filesystem.
>
> http://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html#svn.advanced.reposurls
>
> svn and git are on equal footing when it comes to "extra effort" to
> set up a server. both can do remote operations over the filesystem,
> ssh, http/webdav, or their own private protocol.
>
> Or are you calling running git push "extra effort"? You can always
> pull from the other end if you forget. Or just don't forget.
>
> >
> > So, assuming that vogon and school machines are an unreliable storage
> > location (a valid assumption IMO), git becomes less attractive since
> > there is no offsite backup, and if you do start doing offsite "pushes"
> > you end up with a system no better than SVN.
> >
> > Git offers a lot for group projects, but I see no advantage to it for
> > single-user scenarios.
>
> you're just dead wrong here.
>  - Say you're on a flaky network, or no network. With svn, you're
> forced to accumulate a lot of changes in one giant commit, or stop
> working. gross. With git, you can commit *at any time*, regardless of
> network conditions.
>  - git can do branches, which are awesome and useful for one or one
> million users. You don't use them in svn b/c they are a pain in the
> ass. With git, branching and merging are easy and even joyful, so you
> use it constantly.
>  - cryptographic hashes give you peace of mind that your repository is
> intact.
>
> basically, i see a lot of upsides, and no downsides. the learning
> curve? bah, it's not that big, you're all smart enough, and it's
> extremely worth it.
>
> >
> > Mark
> >
> > On Mon, 2009-01-12 at 22:56 -0800, Joshua J. Berry wrote:
> >> (As an aside: I don't know where people got the idea that distributed
> source
> >> control is complicated.  It's not.  As David said, the early versions of
> Git
> >> were atrocious, but before Git, there was BitKeeper, and Darcs, and
> Mercurial,
> >> and ...  I found Darcs, in particular, to be even simpler than SVN.  But
> >> anyway.)
> >>
> >> On Thursday 08 January 2009 22:36:56 William Tracy wrote:
> >> > If you don't want to spends hours and hours just learning how to use
> >> > the tools, learn Subversion (svn). You'll eventually need to use
> >> > Subversion whenever you have a group project, anyway. (Unless you're
> >> > willing to teach the rest of your team to use Git, because the
> >> > professor won't.)
> >>
> >> The basics take 5 minutes or less to learn, if you're already familiar
> with
> >> CVS or SVN.
> >>
> >> svnadmin init -> git init
> >> svn checkout -> git clone
> >> svn update -> git pull
> >> svn commit -> git commit -a; git push
> >> svn log -> git log
> >> svn diff -> git diff
> >> svn status -> git status
> >>
> >> And of course, there are commands to add, delete and switch branches.
> >>
> >> Or if the rest of your team *insists* on using svn, and you want to use
> git
> >> (assuming you have a standard branches/tags/trunk setup in svn):
> >>
> >> svn checkout -> git svn clone
> >> svn update -> git svn rebase
> >> svn commit -> git commit -a (possibly multiple times); git svn dcommit
> >> etc.
> >>
> >> (Yes, git--or a part of it--knows how to speak SVN.)
> >>
> >> -- Josh
> >>
> >>
> >> _______________________________________________
> >> Cplug mailing list
> >> Cplug at lists.cplug.org
> >> http://lists.cplug.org/mailman/listinfo/cplug
> >
> >
> > _______________________________________________
> > Cplug mailing list
> > Cplug at lists.cplug.org
> > http://lists.cplug.org/mailman/listinfo/cplug
> >
>
> _______________________________________________
> Cplug mailing list
> Cplug at lists.cplug.org
> http://lists.cplug.org/mailman/listinfo/cplug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/cplug/attachments/20090113/851e865d/attachment.htm>


More information about the Cplug mailing list