[CPLUG] Dual-boot Linux
David Sharp
whereami at gmail.com
Tue Jan 13 00:59:58 PST 2009
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
>
More information about the Cplug
mailing list