Hi,
For discussion, here are a few negative points about git as a version
control system. If you read this and think that I am against using
git, you would be wrong. But I do know that each version control
system has its benefits and has its flaws. No system is perfect. In
the future we will likely look back at all of the current ones and
wonder what we were thinking.
My personal favourite git flaw is file history. There is no such
thing. There is commit history, but not file history. This means
that git users often have problems understanding the concept of
copying a file with history (mercurial users are also afflicted). For
example if you have a file that becomes too big to handle, in
subversion you use 'svn copy' two create two files, and then you
delete half of one, and the other half out of the other. If you use
'svn log' for either file, in both cases the history traces back to
the first commit of the original file.
A few others are nicely presented at:
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/
In summary, for a new user who has never used version control before,
git is more complicated in comparison to subversion to learn.
Also note that not everyone is converting to git. A number of
projects flat out reject it as it is not suitable for their
development model. For a good summary of how often git is used in
open source projects, see:
http://www.ohloh.net/repositories/compare
Subversion is not used more than git due to historical reasons.
Regards,
Edward
On 24 July 2013 01:54, Troels Emtekær Linnet <tlinnet@xxxxxxxxx> wrote:
Hi relax developers.
I would like to suggest yet another development possibility by using Git.
Motivation:
Subversion needs an online repository, to store each commits.
Subsequent calls to svn diff > patch will generate the difference
according to the last revision.
Therefore the development at the moment require to:
* make some lines of code
* make a path file and a commit message
* use the support tracker to upload patch and commit message
wait for acceptance
wait for commit to official repository
then do an svn update
then return to point 1
This takes time, and require that repository maintainer is online.
If the above scheme is not followed, the patch files will come out of sync.
I suggest to introduce yet another development possibility by using Git.
I do not suggest to shift away from the GNA! infrasctructure,
I merely suggest to use the powers of Git, to collaborate on a feature
development, before
releasing a patch for review and commit to SVN repository.
This is maintained by a server, who tracks the relax-commit messages at
http://www.mail-archive.com/relax-commits@xxxxxxx/
That server translates the history, and commits to github.
Here a range of developers can pull the latest changes.
Make feature branches. Share those branches.
Make edits online. Use android/iphone apps.
Work on trains/planes etc. Allowing offline commits.
When the feature is ready, easily make a patch file, and upload
to the GNA trackers.
The patch file contains all the commit messages, and
changes between each commit.
That should make it easy to review, and comment on.
Git also allow to squash commits and rewrite commits.
A feature highly appreciated, based on the review comments.
I have made a wiki page, from where we can start discussing.
Here I tried to make an image of my idea.
I am very skilled in MS paint. :-)
http://wiki.nmr-relax.com/Git_development
Best
Troels Emtekær Linnet
_______________________________________________
relax (http://www.nmr-relax.com)
This is the relax-devel mailing list
relax-devel@xxxxxxx
To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel
Re: Suggested faster development with Git, keeping GNA infrastructure