[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Version control tools
From: |
Urs Liska |
Subject: |
Re: Version control tools |
Date: |
Wed, 08 Jan 2014 11:45:45 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
Am 08.01.2014 11:24, schrieb Simon Bailey:
hi,
On Wed, Jan 8, 2014 at 10:20 AM, <address@hidden
<mailto:address@hidden>> wrote:
Joram:
> Simon Bailey:
> > so, my follow up question: why use git as a single user?
>
> I always use git, event git-svn for svn repos.
> Comparing to CVS and SVN, I see these advantages:
>
> - easy branching
what for when working with scores?
Did you see
http://lilypondblog.org/2014/01/why-use-version-control-for-engraving-scores/
?
There's a section about this specific question. The remaining sections
are rather tool-agnostic and apply equally to SVM.
Bottom line is: You can use branches to keep master in a consistent
state. You can work at different spots in parallel, keeping the whole
consistent.
> - I am a heavy user of git rebase
which does what?
> - being able to commit, branch, diff etc. without internet connection
how often do you branch or diff when working on scores?
> that way I can work on a train, for example
hmm. i do a lot of work on trains. however, i have a data plan on my
phone which i use for tethering if i need a connection.
> - this makes the commit often & early paradigm easy
i understand this when working on software programs. but on music scores?
It's exactly the same :-)
Why would you "commit often and early" in software development? mostly
to have fine-grained control on the content of a commit and not to have
a big blob of unrelated changes in a unit. That's exactly the same when
you write scores.
With svn/cvs you need more-or-less a permanent connection to
"the server". With git I can work off-line and update (both ways)
when connected.
i only need the connection with SVN if i'm actually committing. with git
i can commit offline, but then when i get a data connection i have to
commit again to the repo? that's two steps compared to one with SVN. i
still don't get it. especially as i generally commit when i reach
certain milestones or at the end of a working day.
A Git commit isn't about integrating your work with the main line
(remote repository) but about tailoring a coherent changeset. You may
enclose your day's work in a commit but you can (as the other extreme)
enclose a singly typo fix in a commit. With this you have finegrained
control over your project history.
Each of these commits is a separate unit and step that can be inspected,
reverted or modified individually later.
When you contact the server again you don't "commit" (in Git speech) but
"push" your local commits to the server.
Obviously that's not what you're doing so far, so you don't miss it.
But I'm sure it is superior to be able to "tailor" the commit history
locally instead of creating commits depending on the availability of an
internet connection.
don't get me wrong, i'm really trying to find a reason to like git. but
nothing seems different to SVN so far, except for the fact that i have
to commit TWICE...
Urs also pointed out:
On Tue, Jan 7, 2014 at 2:51 PM, Urs Liska <address@hidden
<mailto:address@hidden>> wrote:
Ah, finally one idea about your question, not based on experience
but on randomly read statements: How can you use branches with SVN?
If it's correct that Git branches are conceptually different through
being so exceptionally light-weight then I'd think this _is_ an
advantage even for a single user.
$ svn copy <repo>/trunk <repo>/branch/my-branch
from http://svnbook.red-bean.com/en/1.8/svn.branchmerge.using.html :
<<<
Subversion's repository has a special design. When you copy a directory,
you don't need to worry about the repository growing huge—Subversion
doesn't actually duplicate any data. Instead, it creates a new directory
entry that points to an existing tree. If you're an experienced Unix
user, you'll recognize this as the same concept behind a hard link. As
further changes are made to files and directories beneath the copied
directory, Subversion continues to employ this hard link concept where
it can. It duplicates data only when it is necessary to disambiguate
different versions of objects.
>>>
sounds fairly lightweight to me too... ;) (this is also the same
workflow for tags).
Hm, don't know. As said, my comment was based on arbitrary reading.
Obviously (from skimming through that linked page) the branching concept
between SVN and Git is _very_ different.
I can't really judge that, but as far as I've read this area is one of
the major improvements of Git over the older VCSs.
Urs
regards,
sb
--
Do not meddle in the affairs of trombonists, for they are subtle and
quick to anger.
_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user
--
Urs Liska
www.openlilylib.org
- Re: Survey: Git (G)UIs, (continued)
- Re: Survey: Git (G)UIs, James Harkins, 2014/01/06
- Re: Survey: Git (G)UIs, Paul Morris, 2014/01/06
- Version control tools (was: Survey: Git (G)UIs), Urs Liska, 2014/01/07
- Re: Version control tools (was: Survey: Git (G)UIs), Simon Bailey, 2014/01/07
- Re: Version control tools, Noeck, 2014/01/07
- Re: Version control tools, karl, 2014/01/08
- Re: Version control tools, Simon Bailey, 2014/01/08
- Re: Version control tools, Simon Bailey, 2014/01/08
- Re: Version control tools,
Urs Liska <=
- Re: Version control tools, Noeck, 2014/01/08
Re: Version control tools (was: Survey: Git (G)UIs), Henning Hraban Ramm, 2014/01/08