Shortcomings in the current scheme of Version Control???
15 posts
• Page 2 of 2 • 1, 2
Re: Shortcomings in the current scheme of Version Control???
Neeraj, you are not only looking for a SCM (Source Code Management System), you are also looking for a RMS (Release Management System).
http://en.wikipedia.org/wiki/Release_management
All:
GitHub is used heavily in the Linux community but there is a particular reason for that: the Linux guys were forced to stop using their SCM, BitKeeper, because the company that owned it was not prepared to grant rights to the Open Source community any more, so HE (Linus) himself started writing GitHub. Of course that a) gave it a head start and b) it never had a reputation problem.
Also, it's particularily addressing the problems of the Linux Kernel developers: they are spread all over the world, and they don't want/cannot rely on Internet access.
Outside the Linux Kernel development community GitHub has also been successful but it is far from taking over from SubVersion and even CVS when we look at companies.
Many Open Source developers not involved in Linux Kernel development consider SourceForge as the right tool. SourceForge hosts 430,000 Open Source projects and has 3.7 million registered users. If we shall save stuff outside the APL wiki then I would clearly vote for SourceForge.
Saving stuff there however does not mean that we have to use it while developing.
BTW, there are claims that Mercurial outperforms GitHub in may respects (Joe Spolski).
Do we need GitHub or SourceForge support for attracting new people to Dyalog? Not at all. What we need is just support for any SCM that fits the bill of a professinal developer. acre can do this itself, and with SALT any file oriented SCM can be used.
This is absolutely essential because these days (most) professional developers don't even consider to look at a programming language that does not support (or cannot be supported by) an SCM, and rightly so.
So, it was CVS 10 years ago, it was SubVersion 5 years ago, it is GitHub right now, it might be Mercurial in 5 years and God-knows-what in 10 years. Doesn't matter, really.
http://en.wikipedia.org/wiki/Release_management
All:
GitHub is used heavily in the Linux community but there is a particular reason for that: the Linux guys were forced to stop using their SCM, BitKeeper, because the company that owned it was not prepared to grant rights to the Open Source community any more, so HE (Linus) himself started writing GitHub. Of course that a) gave it a head start and b) it never had a reputation problem.
Also, it's particularily addressing the problems of the Linux Kernel developers: they are spread all over the world, and they don't want/cannot rely on Internet access.
Outside the Linux Kernel development community GitHub has also been successful but it is far from taking over from SubVersion and even CVS when we look at companies.
Many Open Source developers not involved in Linux Kernel development consider SourceForge as the right tool. SourceForge hosts 430,000 Open Source projects and has 3.7 million registered users. If we shall save stuff outside the APL wiki then I would clearly vote for SourceForge.
Saving stuff there however does not mean that we have to use it while developing.
BTW, there are claims that Mercurial outperforms GitHub in may respects (Joe Spolski).
Do we need GitHub or SourceForge support for attracting new people to Dyalog? Not at all. What we need is just support for any SCM that fits the bill of a professinal developer. acre can do this itself, and with SALT any file oriented SCM can be used.
This is absolutely essential because these days (most) professional developers don't even consider to look at a programming language that does not support (or cannot be supported by) an SCM, and rightly so.
So, it was CVS 10 years ago, it was SubVersion 5 years ago, it is GitHub right now, it might be Mercurial in 5 years and God-knows-what in 10 years. Doesn't matter, really.
-
kai - Posts: 141
- Joined: Thu Jun 18, 2009 5:10 pm
- Location: Hillesheim / Germany
Re: Shortcomings in the current scheme of Version Control???
I heard at Deerfield Beach Conference that Git & GitHub were the officially recommended SCM / Release Management tools. When I look at SCM I do not differentiate it much from Release Management. What good is SCM if not able to help release successive versions of working Software.
- neeraj
- Posts: 82
- Joined: Wed Dec 02, 2009 12:10 am
- Location: Ithaca, NY, USA
Re: Shortcomings in the current scheme of Version Control???
> What good is SCM if not able to help release successive versions of working Software.
True, but a release management software can do more.
The two are identical when you manage to have just different versions of your software. Microsoft Word would be an example.
If you have individual releases for different customer groups (or worse for every single customer a tailored release) then it's a different story.
To a certain extend you can simulate that by branching out, but a real release management system is much better at this.
True, but a release management software can do more.
The two are identical when you manage to have just different versions of your software. Microsoft Word would be an example.
If you have individual releases for different customer groups (or worse for every single customer a tailored release) then it's a different story.
To a certain extend you can simulate that by branching out, but a real release management system is much better at this.
-
kai - Posts: 141
- Joined: Thu Jun 18, 2009 5:10 pm
- Location: Hillesheim / Germany
Re: Shortcomings in the current scheme of Version Control???
kai wrote:If you have individual releases for different customer groups (or worse for every single customer a tailored release) then it's a different story.
A bit of a side comment: That's a thing i avoid like the pest (if one can express it that way). I guess everyone knows all about this... For my part, the simulator has ca 4 GB in 18000 data files, of which 'assets' is 211 MB in 120 folders. Custmization and versioning happens with configuration files and a rolling file name convention. The single .exe must survive in practically any environment.
Long ago, Morten said 1 namespace = 1 developer/team, and that's a super golden way, imho. I'd rather let the single system grow and keep it compatible and tolerant, holding multiple parallel customizations, than extract/let off customized versions from it...
I realize this isn't unfortunately always possible. I just happen to be lucky atm, as it is possible for me. :-) But over the years, thinking ahead (long ahead, years) while keeping it in tight hands has saved me from a million potential problems on the way.
Never will i lose the grip so much, that i have to let a version management system tell me what i have. Halleluja! :-)
- Tomas Gustafsson
- Posts: 101
- Joined: Mon Sep 19, 2011 6:43 pm
Re: Shortcomings in the current scheme of Version Control???
Tomas wrote:That's a thing i avoid like the pest (if one can express it that way)
I think we all take your meaning but in colloquial English we tend to say "avoid like the plague" but an interesting alternative is "I wouldn't touch it with a barge pole."
-
Phil Last - Posts: 628
- Joined: Thu Jun 18, 2009 6:29 pm
- Location: Wessex
15 posts
• Page 2 of 2 • 1, 2
Return to Source Code Management
Who is online
Users browsing this forum: No registered users and 0 guests
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group