Hi Folks
> I have been using git for a few sub-projects, like the PHP classes as
> an excuse to learn it. I can see why some people like git. It does
> some things quite well.
Interesting that you didn't already take the plunge and switch if you
already tried it?
Just as a datapoint, for me using it briefly was a complete epiphany on
how I could change (improve) my development cycle. I love that a DVCS
basically makes "commits" the unit of work and that these basically
become "portable". So I love that I can create branches so easily,
fiddle around with something, create some changes, and then basically
commit a "feature branch". I can then easily pull several features from
different branches into some master branch. Especially when it's
multiple developers independently working on these individual feature
branches it feels like magic that you can still quite easily pull all
the features back upstream!
The second big benefit that *I* found was that the quality of my commits
increased. Arguably this isn't a git feature and works just as well if
you use svn, however, I think because I now get benefit from having the
"git log" tell a story, instead I now commit lots of small individual
commits rather than with svn where I tended to just "checkpoint" the
code every so often... I use the command line client and I find it's
very easy to tease apart even a large chunk of work into individual
changes...
> Mercurial, maybe but I haven't learned it yet and don't really want to
> take the time to yet. However so far what I have heard is that it
> does offer some of the revision control system guarantees notably
> missing from git.
I'm not sure about "guarantees", but yes, mercurial is considered to be
"opinionated" and directs workflow quite a bit, whereas Git is more like
a toolkit that allows you to generate your own workflow, but throws more
of that back on the owner to decide. I don't use mercurial, but the
arguments in favour sound interesting. From what I can see users tend
to arrive at one of git/hg/bzr and it's a life changing event and at
that point they tend to get stuck into whatever they first tried (or
works best initially). As such seems like personal choice to a large
extent, but they are all excellent and very powerful tools, I don't
think the exact choice is all that important
> Thing you have to remember about git is it isn't a revision control
> system, but rather a change management toolkit and it doesn't offer
> the basic guarantees of a revision control system by default. For
> example it is possible to overwrite past changes/revisions using git.
> Of course you can build a solution that does offer these guarantees
> but the more complicated you make it the harder it will be for
> cross-platform development to happen,
Hmm, I suspect you have some point you are trying to make here, but I'm
afraid it's not clear to me, and whilst I probably misunderstand, I
would disagree with the points above?
Fundamentally both Git and SVN are pointed at some directory and they
simply checkpoint the files in those directories whenever you push a
button. The difference between them is really only about how flexible
they are with change and branch management (IMHO).
So for example if you have two copies of an svn repo, with changes in
both, then my svn skills would not easily merge the two sets of
changes. However, such a task is very straight forward (for me) in git.
Creating feature branches and managing release branches is similarly
straightforward in git, but I'm quite unsure about a good process to
emulate the same in svn (eg I have some feature that I make available as
a patch to kernels 3.1-6, ie as 6 separate branches. I fix some bug in
the core feature and I want to pull that change to each of the 6
branches and at the same time update the patch to apply cleanly to the
latest version of each kernel version - this is fairly trivial in git,
but I'm unsure of an efficient process in svn)
With regards to overwriting past changes, this is trivially prevented
and most significant public repos have that enforced. Even the defaults
cause pushing changes to history to require additional options and some
deeper knowledge of git to make it happen. So overwriting history is
simply an option that you can enable on your public repo, but there is
no real challenge to turning it off and enforcing it (because it's
server side, the choice of client makes no difference)
So I don't see any complication with preventing history revision, nor
anything which complicates cross platform development. I believe it
*does* offer the basic guarantees of a revision control system and can
be considered a superset of svn... (By all means lets argue any specific
weaknesses, but lets not get into a flame war on A vs B, there are
certainly pros and conns, I just wanted to tackle that all of the
features of SVN can be achieved with git without any great effort, IMHO)
> Ideally we'd add shell scripts and .bat files that would allow people
> to run identical series of commands to do things like submit changes
> back etc. that would run on all platforms. We already have some
> unaddressed issues with OSX and shell scripts. I don't really want to
> multiply these.
Again, probably you have specific things in mind, but I'm unsure what
you might be thinking of? I can't think of any significant git hosted
projects which use any form of bat or shell scripts to assist with
commits? In fact I can't think of a particular reason to use shell
scripts? (git pull, git checkout, git push...)
Perhaps you could describe why shell scripts are needed? Perhaps git
would actually make these shell scripts disappear? Note that with git
it's normal and quite straightforward to install hooks both client and
server side into the repository itself that run every time you do
certain tasks. This for example can be used to refuse to allow someone
to commit code which doesn't say match certain style guidelines or pass
some smoketest or say decline changes to history in certain branches, or
send emails on commit, etc.
http://git-scm.com/book/en/Customizing-Git-Git-Hooks
> In this scenario we would see git for now largely as a
> merge-management tool for general use. However at present, I think
> that a lot of things (including review of commits) will be made harder
> or at least more inconvenient, rather than easier by a move to git. I
> am also somewhat concerned about necessitating more complexity
> regarding processes around the project.
Ultimately the main developers will decide what makes things harder or
easier, but if I could draw your attention to a huge groundswell of
people who tried git (or HG/BZR) and decided that they made things
easier? I'm not claiming to get a vote, but definitely for me git is
vastly easier to manage commits
Example of practical ways I know use commits is that I regularly examine
individual code changes in the commit history in github and learn from
them. eg, I recently synced to twitter bootstrap and formatting broke
in Firefox, in a few minutes I could track down the change which caused
it, add a comment, raise an issue and my own fork continues to track
master with a simple "git pull" yet it's got that change reverted:
https://github.com/twitter/bootstrap/commit/fa38ab573b99e6e65184626b37867f50802b228f#less/mixins.less
Encouraging forks to stay on a single server is also interesting, eg in
the case of bitbucket/github, etc. I often find it interesting to be
able to go code spelunking to grab bug fixes and features:
https://github.com/ewildgoose/ym4r_gm/network
Anyway, these are all reasons why *I* very much value git vs svn,
however, I do respectfully realise that this decision needs to be driven
by the main developers. Hopefully the above gives you a reason to at
least investigate the option and an example of someone enthusiastic who
believes there is value there if you choose to investigate further. A
few other opinions (chosen because they are hopefully fairly down the
line and not too emotionally biased...):
http://kolab.org/blog/adams/2012/08/16/cyrus-imap-what-happened-when-they-switched-git
http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git
http://www.gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/
http://www.heartmindcode.com/blog/2011/03/svn-users-why-you-should-switch-to-git/
http://blog.geoserver.org/2012/07/09/geoserver-has-moved-to-github/
Cheers
Ed W
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
