Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #77503 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2015-12-01 12:52 +0000 |
| Last post | 2015-12-01 12:24 -0800 |
| Articles | 20 on this page of 151 — 24 participants |
Back to article view | Back to comp.lang.c
// comments and \ BartC <bc@freeuk.com> - 2015-12-01 12:52 +0000
Re: // comments and \ me <self@example.org> - 2015-12-01 13:08 +0000
Re: // comments and \ Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-01 08:20 -0500
Re: // comments and \ me <self@example.org> - 2015-12-01 13:36 +0000
Re: // comments and \ Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-01 09:03 -0500
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 14:14 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 07:40 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 08:55 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 17:15 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 09:58 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 18:11 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 10:18 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 18:20 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 11:07 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 11:39 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 12:33 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 01:05 +0000
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:30 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 20:59 +0100
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-01 15:22 -0500
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 20:37 +0000
Re: // comments and \ Robert Wessel <robertwessel2@yahoo.com> - 2015-12-01 14:56 -0600
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 22:11 +0100
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:01 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 00:45 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 07:52 -0700
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 15:19 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 08:29 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 15:35 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 09:21 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 16:41 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 10:15 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:24 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:43 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:05 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-02 11:40 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 04:29 -0800
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 19:11 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-01 20:43 +0000
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 21:04 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-01 21:16 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:12 -0800
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-02 11:52 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 04:40 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 13:55 +0100
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-02 13:56 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 15:24 +0100
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 06:54 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 16:40 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-02 18:24 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-02 20:27 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 23:22 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-03 00:57 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-03 23:44 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-03 21:17 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 00:43 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:32 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 16:06 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-05 13:10 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:18 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-06 14:26 -0600
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-03 12:45 +0100
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-04 11:45 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-04 04:20 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 14:20 +0100
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-04 10:05 -0500
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 17:31 +0100
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 17:24 -0600
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-04 18:50 -0500
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:34 -0600
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-10 20:40 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-04 09:36 -0800
Re: // comments and \ Richard Damon <Richard@Damon-Family.org> - 2015-12-05 09:05 -0500
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 17:42 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-06 22:23 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-07 21:59 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 15:50 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-05 18:17 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:01 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 03:05 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 04:07 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 04:37 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 05:05 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:19 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 13:59 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 06:09 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 07:30 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 18:55 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:23 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:22 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 21:06 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-05 13:14 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:09 +0000
Re: // comments and \ mark.bluemel@gmail.com - 2015-12-03 06:15 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-02 08:28 -0700
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 09:01 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-02 21:52 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 16:55 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-03 13:11 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-03 23:21 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 11:22 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 01:12 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:39 -0600
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-04 11:14 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-04 12:25 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 14:23 +0100
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:00 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:46 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 20:36 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 20:37 -0700
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 14:26 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 14:32 +0000
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 14:52 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 16:15 +0100
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 15:28 +0000
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 01:26 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:12 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:17 +0000
Re: // comments and \ Robert Wessel <robertwessel2@yahoo.com> - 2015-12-01 12:32 -0600
Re: // comments and \ Nobody <nobody@nowhere.invalid> - 2015-12-02 00:01 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 07:08 -0800
Re: // comments and \ Nobody <nobody@nowhere.invalid> - 2015-12-02 21:05 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 14:22 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 14:48 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 23:37 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 17:10 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 19:24 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-03 04:10 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 21:49 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-03 07:28 -0700
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 09:12 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 06:53 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 15:41 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-03 15:56 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 16:44 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-03 17:29 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 19:10 -0800
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 21:59 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 07:52 -0700
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:21 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:26 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 10:50 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 10:49 -0800
Re: // comments and \ Geoff <geoff@invalid.invalid> - 2015-12-01 11:34 -0800
Re: // comments and \ David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:44 -0500
Re: // comments and \ "Charles Richmond" <numerist@aquaporin4.com> - 2015-12-23 14:35 -0600
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-23 13:00 -0800
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-23 16:58 -0500
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-23 14:21 -0800
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-23 16:55 -0500
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-01 12:24 -0800
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-12-06 14:26 -0600 |
| Message-ID | <n4258p$q8t$1@dont-email.me> |
| In reply to | #77956 |
Jorgen Grahn wrote: > On Sat, 2015-12-05, Les Cargill wrote: >> Jorgen Grahn wrote: > > [ClearCase] >>> - "Config specs" which decide which branch you look at/work on >>> tended to become spaghetti code, and a bug there could ruin >>> your work. >> >> Just awful. You needed a version control system outside ClearCase >> to control them. > > Yes. I wrote one myself ;-) and used three or four others of varying > quality. Every project rolled their own. > > Config specs were a neat idea, They were a *messy* idea :) Tags and branches are neater. The basic SVN workflow is much less error prone. I now Officialy(tm) need to try git to exploit the "many smaller commit" feature, though. > which kept policy away from the core > ClearCase functionality ... This was designed to appeal to "change control boards." > but they also dumped the policy decisions > in the laps of people who couldn't usually handle them. > > /Jorgen > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-03 12:45 +0100 |
| Message-ID | <n3p9rq$akb$1@dont-email.me> |
| In reply to | #77646 |
On 02/12/15 19:24, Jorgen Grahn wrote: > On Wed, 2015-12-02, David Brown wrote: >> On 02/12/15 12:52, BartC wrote: > ... >>> Thanks, but I prefer using my own tools as I've always have done. > ... >> If you want to use git on Windows, get TortoiseGit: > ... >> However, for someone new to version control systems, especially a >> Windows user, I would not recommend git. I would suggest subversion >> (with TortoiseSvn for windows). Git is significantly more powerful - >> but also significantly more complex. Compared to having a bunch of >> files in a directory, subversion gives you an extra dimension - it lets >> you track changes over time. Git gives you two extra dimensions - time, >> and also branches. So with a view to learning to walk before you try to >> run, and because walking is often perfectly sufficient and a big >> improvement over standing still, I suggest you learn about subversion. >> And since subversion has always been a cross-platform solution from its >> conception, it does not feel as alien on Windows. > > I don't think we can convince BartC to do anything he hasn't done in > the past decades ... But in general: > > I think that unless you /know/ you'll be forced to use Subversion at > some point, it's better to skip that step and go directly to Git. > Because it's not really a /step/ -- svn and Git require that you think > in different ways. And Git is a lot more polished: better documented, > better practical features for everyday use. I disagree that git is more polished, or better documented, or has better practical features for everyday use. It certainly has features that svn does not, and I appreciate what you say that git and svn require different ways of thinking. But I still think that svn is conceptually easier (you have one server, checkins go directly to the server - you don't have the mix of local history and remotes), and a smaller step from no version control - and I think it is easier to learn git from svn than git from nothing, even though moving from svn to git means some significant changes in the way you work. The other thing about svn is that it is that it works nicely and conveniently with a range of files - in particular, binary files are not an issue. git is great for pure programming source code - but less great for storing entire projects that may contain documentation in binary formats, CAD designs, and all sorts of other files. > > IMO, one first way to use Git could be to > - Ignore remotes; just do a 'git init' and do local version control > like with Walter F. Tichy's 1980s creation, rcs(1). That is okay for some initial testing, but I always recommend having a central repository. It means you are not dependent on the one PC for reliability, and can easily move the project around between different client machines. > - Ignore branches; stick to master. Again, that's good to start with. But if you don't learn about branches, you lose much of the point of git (and can just as well stick to svn :-) ). > - Focus on creating a sequence of well-defined and correct commits, > and learn how to compare them. Learn how to use 'git rebase -i' > and 'commit --amend' to make this happen. Yes, do plenty of trial-and-error and read some tutorials to get a few useful, basic commands. Get used to them before doing anything "fancy".
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-12-04 11:45 +0000 |
| Message-ID | <56617a2a.5013750@news.xs4all.nl> |
| In reply to | #77725 |
David Brown <david.brown@hesbynett.no> wrote: > The other thing about svn is that it is that it works nicely and > conveniently with a range of files - in particular, binary files are not > an issue. git is great for pure programming source code - but less > great for storing entire projects that may contain documentation in > binary formats, CAD designs, and all sorts of other files. Wha... hold on, doesn't git know that we live in an interactive world now? Graphics files have been an integral, unmissable part of programming for, well, decades! And help files... OK, it's an open source project, its main users don't know what the words "help file", "manual" or "documentation" mean, but still, for those of us who have to face _real_, non-geek, users, it'd be nice if it handled them. If it handles only source code and not help files, I guarantee you that the two _will_ get out of sync, which already happens far too often. > > IMO, one first way to use Git could be to > > - Ignore remotes; just do a 'git init' and do local version control > > like with Walter F. Tichy's 1980s creation, rcs(1). > > That is okay for some initial testing, but I always recommend having a > central repository. It means you are not dependent on the one PC for > reliability, and can easily move the project around between different > client machines. Erm... > > - Ignore branches; stick to master. > > Again, that's good to start with. But if you don't learn about > branches, you lose much of the point of git (and can just as well stick > to svn :-) ). Erm... Those are very nice for teams of programmers who need to work together (or anti-together) on several branches of a large project. Explain to me again how version control, _particularly_ git, is useful for a stand-alone programmer who has the discipline to make backups? I'm especially interested in a justification for either installing a whole new server, or trusting my (possibly proprietary, certainly personally written) code to another server in either "The Cloud" or the USA. Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-04 04:20 -0800 |
| Message-ID | <ee3a74f2-1f19-4cfd-8d8e-e9705cfa18c6@googlegroups.com> |
| In reply to | #77808 |
On Friday, December 4, 2015 at 11:45:11 AM UTC, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > > > The other thing about svn is that it is that it works nicely and > > conveniently with a range of files - in particular, binary files are not > > an issue. git is great for pure programming source code - but less > > great for storing entire projects that may contain documentation in > > binary formats, CAD designs, and all sorts of other files. > > Wha... hold on, doesn't git know that we live in an interactive world > now? Graphics files have been an integral, unmissable part of > programming for, well, decades! > git can track graphics files. But it only "understands" human-generated text. So if we make two edits to a human-generated text document, git will tell us in a human-understandable way what the differences are, and normally it will give three simple options - accept theirs, accept our, or merge, and the merge will be what a human understands as accepting both edits. When the material isn't human-generated text, everything is more difficult for it. It can't do shape recognition and delete the apples whilst adding the cherry. If the graphics file is text, it can of course put it through the algorithm, but results are often bad - deleting the apple will often break the coherency of the graphics file format in a way that deleting the word 'apple" from human-composed text doesn't. > > Explain to me again how version control, _particularly_ git, is useful > for a stand-alone programmer who has the discipline to make backups? > I'm especially interested in a justification for either installing a > whole new server, or trusting my (possibly proprietary, certainly > personally written) code to another server in either "The Cloud" or the > USA. > Essentially you have tagged and managed backups in the git repository. So a bit of a win over doing it by hand. Then you can merge back if you choose to fork development, so you can realise version 1.0 to your users, and start work on version 2.0. A bug report comes in, so you fix it in version 1.0 and release 1.1. After a couple of weeks, it's obvious that the bug fix really fixed the problem, so you then merge in 1.1 to the current build of 2.0, and the bug is fixed in 2.0 as well. if the bug fix introduced a new bug, then you either go back to 1.0 and start from scratch, or go to 1.1 and fix the fix, depending on what you judge is the best approach. Then you give it another two weeks and merge from that version.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-04 14:20 +0100 |
| Message-ID | <n3s3qq$8gk$1@dont-email.me> |
| In reply to | #77808 |
On 04/12/15 12:45, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> The other thing about svn is that it is that it works nicely and >> conveniently with a range of files - in particular, binary files are not >> an issue. git is great for pure programming source code - but less >> great for storing entire projects that may contain documentation in >> binary formats, CAD designs, and all sorts of other files. > > Wha... hold on, doesn't git know that we live in an interactive world > now? Graphics files have been an integral, unmissable part of > programming for, well, decades! And help files... OK, it's an open > source project, its main users don't know what the words "help file", > "manual" or "documentation" mean, but still, for those of us who have to > face _real_, non-geek, users, it'd be nice if it handled them. If it > handles only source code and not help files, I guarantee you that the > two _will_ get out of sync, which already happens far too often. Actually, git is fairly well documented (like many major open source projects). And it /does/ handle binary formats - it's just more effort than with subversion. > >>> IMO, one first way to use Git could be to >>> - Ignore remotes; just do a 'git init' and do local version control >>> like with Walter F. Tichy's 1980s creation, rcs(1). >> >> That is okay for some initial testing, but I always recommend having a >> central repository. It means you are not dependent on the one PC for >> reliability, and can easily move the project around between different >> client machines. > > Erm... > >>> - Ignore branches; stick to master. >> >> Again, that's good to start with. But if you don't learn about >> branches, you lose much of the point of git (and can just as well stick >> to svn :-) ). > > Erm... > > Those are very nice for teams of programmers who need to work together > (or anti-together) on several branches of a large project. > > Explain to me again how version control, _particularly_ git, is useful > for a stand-alone programmer who has the discipline to make backups? > I'm especially interested in a justification for either installing a > whole new server, or trusting my (possibly proprietary, certainly > personally written) code to another server in either "The Cloud" or the > USA. > For those with a single immortal computer, perfect memories, and who never make mistakes, version control is not very useful. But for the rest of us... I'll agree that for a single programmer who does everything on a single machine, it might be excessive to have a server involved in their version control system. Subversion can work with a local file-based repository and no server, git can work with a purely local repository (since all the history is also on the same machine). But setting up a subversion or git server is not particularly hard, and it is very useful if you have more than one computer (a desktop and a laptop, a real PC and a couple of test virtual machines, etc.). Using version control rather than lots of backup versions is easier, more informative (you have the log messages, times, list of changes, etc.), more efficient, and faster for things like comparison between versions. And once you progress, you can use features that are not easily available in a backup-copy system, such as merges, branches, tagging, bisecting, etc.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-12-04 10:05 -0500 |
| Message-ID | <n3s9vu$1sg$1@dont-email.me> |
| In reply to | #77808 |
On 12/04/2015 06:45 AM, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> The other thing about svn is that it is that it works nicely and >> conveniently with a range of files - in particular, binary files are not >> an issue. git is great for pure programming source code - but less >> great for storing entire projects that may contain documentation in >> binary formats, CAD designs, and all sorts of other files. > > Wha... hold on, doesn't git know that we live in an interactive world > now? Graphics files have been an integral, unmissable part of > programming for, well, decades! And help files... OK, it's an open > source project, its main users don't know what the words "help file", > "manual" or "documentation" mean, but still, for those of us who have to > face _real_, non-geek, users, it'd be nice if it handled them. If it > handles only source code and not help files, I guarantee you that the > two _will_ get out of sync, which already happens far too often. I don't know git, so I don't know why it's not good for storing such file types. However, I can assure you that neither svn nor any other version control system that I'm familiar with does a good job with non-text files. They can all store and retrieve multiple versions of such files, but the sticking point comes when you need to display differences between two different versions of a file in an intelligible manner. That can only be done by understand the format of those files, and using a format-specific way of displaying those differences. I haven't seen any version control system that could difference anything other than text files intelligibly. In principle, one could register a particular difference display routine for each registered file type, but how many file types have a specialized routine available for displaying such differences? ...> Explain to me again how version control, _particularly_ git, is useful > for a stand-alone programmer who has the discipline to make backups? > I'm especially interested in a justification for either installing a > whole new server, or trusting my (possibly proprietary, certainly > personally written) code to another server in either "The Cloud" or the > USA. I can't think of any reason why a stand-alone programmer would need to install one of these systems on a separate server in order to make use of it, so there would not seem to be any need to justify doing so. I've found version control useful precisely when I've made several different version of the same thing, with a lot of similarities between those versions. A version control system, properly used, makes it easy to keep track of the relationships between those versions. If you've never had so many different versions of something that you've had trouble keeping track of them, then you don't need a version control system. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-04 17:31 +0100 |
| Message-ID | <n3sevk$nb8$1@dont-email.me> |
| In reply to | #77825 |
On 04/12/15 16:05, James Kuyper wrote: > On 12/04/2015 06:45 AM, Richard Bos wrote: >> David Brown <david.brown@hesbynett.no> wrote: >> >>> The other thing about svn is that it is that it works nicely and >>> conveniently with a range of files - in particular, binary files are not >>> an issue. git is great for pure programming source code - but less >>> great for storing entire projects that may contain documentation in >>> binary formats, CAD designs, and all sorts of other files. >> >> Wha... hold on, doesn't git know that we live in an interactive world >> now? Graphics files have been an integral, unmissable part of >> programming for, well, decades! And help files... OK, it's an open >> source project, its main users don't know what the words "help file", >> "manual" or "documentation" mean, but still, for those of us who have to >> face _real_, non-geek, users, it'd be nice if it handled them. If it >> handles only source code and not help files, I guarantee you that the >> two _will_ get out of sync, which already happens far too often. > > I don't know git, so I don't know why it's not good for storing such > file types. However, I can assure you that neither svn nor any other > version control system that I'm familiar with does a good job with > non-text files. They can all store and retrieve multiple versions of > such files, but the sticking point comes when you need to display > differences between two different versions of a file in an intelligible > manner. That can only be done by understand the format of those files, > and using a format-specific way of displaying those differences. I > haven't seen any version control system that could difference anything > other than text files intelligibly. In principle, one could register a > particular difference display routine for each registered file type, but > how many file types have a specialized routine available for displaying > such differences? In principle - and in practice - it is possible to have specialised difference displays for binary files. I haven't used the feature very often, and haven't experimented on support in different OS's, tools, etc. But on Windows, with TortoiseSvn, and LibreOffice, you can use the SVN log viewer to see when an odt file has changed, click on the "compare", and get a LibreOffice window showing details of the differences. The electronics design software that we use, Altium, has builtin support for subversion. You can, from with the program, compare revisions. Comparison of binary formats requires a program that can show the changes, and either integration in that program for using the version control system, or hooks in the version control client for calling the program. Subversion comes as a library that can be (relatively) easily used by other programs, and hooks from TortoiseSvn are certainly possible. Whether there is much use in viewing such differences, is another matter - it depends on the type of format. > > ...> Explain to me again how version control, _particularly_ git, is useful >> for a stand-alone programmer who has the discipline to make backups? >> I'm especially interested in a justification for either installing a >> whole new server, or trusting my (possibly proprietary, certainly >> personally written) code to another server in either "The Cloud" or the >> USA. > > I can't think of any reason why a stand-alone programmer would need to > install one of these systems on a separate server in order to make use > of it, so there would not seem to be any need to justify doing so. A stand-alone programmer does not necessarily mean one person with one computer - it can easily mean a main development PC at the office, another PC at home, a laptop while travelling. And perhaps deployment of code at a customer's site is done by version control to make testing and modification easier. And of course the programmer could wisely consider his Windows development machine to be unreliable - hardware failure, software failure, malware, and user error can all lead quickly to disaster. A version control system on a separate server works as a good and convenient backup of the code. It is clearly not a necessity, but the advantages should not be ruled out simply because we are talking about a single developer rather than a team. > I've found version control useful precisely when I've made several > different version of the same thing, with a lot of similarities between > those versions. A version control system, properly used, makes it easy > to keep track of the relationships between those versions. If you've > never had so many different versions of something that you've had > trouble keeping track of them, then you don't need a version control system. >
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-12-04 17:24 -0600 |
| Message-ID | <n3t6ua$sjv$2@dont-email.me> |
| In reply to | #77825 |
James Kuyper wrote: > On 12/04/2015 06:45 AM, Richard Bos wrote: <snip> > > I can't think of any reason why a stand-alone programmer would need to > install one of these systems on a separate server in order to make use > of it, so there would not seem to be any need to justify doing so. Being able to to do the equivalent of "svn revert" is mighty useful. > I've found version control useful precisely when I've made several > different version of the same thing, with a lot of similarities between > those versions. A version control system, properly used, makes it easy > to keep track of the relationships between those versions. If you've > never had so many different versions of something that you've had > trouble keeping track of them, then you don't need a version control system. > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-12-04 18:50 -0500 |
| Message-ID | <n3t8o2$47q$1@dont-email.me> |
| In reply to | #77856 |
On 12/04/2015 06:24 PM, Les Cargill wrote: > James Kuyper wrote: >> On 12/04/2015 06:45 AM, Richard Bos wrote: > <snip> >> >> I can't think of any reason why a stand-alone programmer would need to >> install one of these systems on a separate server in order to make use >> of it, so there would not seem to be any need to justify doing so. > > Being able to to do the equivalent of "svn revert" is mighty useful. Is that not possible when doing a single-system install? If so, why? I know nothing about git, but when I've installed similar software, I've usually had the option to install the server on the same machine where I am using the service, without any loss of functionality. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-12-04 20:34 -0600 |
| Message-ID | <n3ti1e$uks$2@dont-email.me> |
| In reply to | #77858 |
James Kuyper wrote: > On 12/04/2015 06:24 PM, Les Cargill wrote: >> James Kuyper wrote: >>> On 12/04/2015 06:45 AM, Richard Bos wrote: >> <snip> >>> >>> I can't think of any reason why a stand-alone programmer would need to >>> install one of these systems on a separate server in order to make use >>> of it, so there would not seem to be any need to justify doing so. >> >> Being able to to do the equivalent of "svn revert" is mighty useful. > > Is that not possible when doing a single-system install? If so, why? I am sure it *is* possible. Sorry; you said "seperate" server. > I > know nothing about git, but when I've installed similar software, I've > usually had the option to install the server on the same machine where I > am using the service, without any loss of functionality. > I can't imagine not being able to. If you could not do that, I would spawn a VM to be the server. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-12-10 20:40 +0000 |
| Message-ID | <5669e308.29559890@news.xs4all.nl> |
| In reply to | #77825 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 12/04/2015 06:45 AM, Richard Bos wrote: > ...> Explain to me again how version control, _particularly_ git, is useful > > for a stand-alone programmer who has the discipline to make backups? > > I'm especially interested in a justification for either installing a > > whole new server, or trusting my (possibly proprietary, certainly > > personally written) code to another server in either "The Cloud" or the > > USA. > > I can't think of any reason why a stand-alone programmer would need to > install one of these systems on a separate server in order to make use > of it, so there would not seem to be any need to justify doing so. > I've found version control useful precisely when I've made several > different version of the same thing, with a lot of similarities between > those versions. A version control system, properly used, makes it easy > to keep track of the relationships between those versions. If you've > never had so many different versions of something that you've had > trouble keeping track of them, then you don't need a version control system. Thank you for explaining this - and for confirming that I really don't need all the extra hassle. Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-04 09:36 -0800 |
| Message-ID | <ln610eqfnq.fsf@kst-u.example.com> |
| In reply to | #77808 |
raltbos@xs4all.nl (Richard Bos) writes:
> David Brown <david.brown@hesbynett.no> wrote:
>> The other thing about svn is that it is that it works nicely and
>> conveniently with a range of files - in particular, binary files are not
>> an issue. git is great for pure programming source code - but less
>> great for storing entire projects that may contain documentation in
>> binary formats, CAD designs, and all sorts of other files.
>
> Wha... hold on, doesn't git know that we live in an interactive world
> now? Graphics files have been an integral, unmissable part of
> programming for, well, decades! And help files... OK, it's an open
> source project, its main users don't know what the words "help file",
> "manual" or "documentation" mean, but still, for those of us who have to
> face _real_, non-geek, users, it'd be nice if it handled them. If it
> handles only source code and not help files, I guarantee you that the
> two _will_ get out of sync, which already happens far too often.
For most simple operations, git handles binary files the same way it
handles text files. You can add a binary file to a git repo, modify it,
check in a new version, retreive old versions, etc.
But there are some problems.
If you commit a large text file, change a few lines, then commit the
updated version, git will store the two versions reasonably efficiently;
it doesn't store the entire duplicated content of both versions.
Small changes in binary files tend to be more difficult to isolate. If,
for example, you commit a large image file, tweak it to darken it a
little bit, then commit the updated version, git will probably have to
store both versions in their entirety, since it won't be able to figure
out a compact way to represent the differences. If you commit a lot of
different versions of the file, you're effectively going to have a full
copies of each version. And since git is a distributed system, all
those copies are going to be stored on your local system.
There are some add-ons that try to deal with this kind of thing (Google
"git large file storage" for example).
For text files, git makes it reasonably easy to merge two different
versions into a new one. If the changes are isolated within the file,
git does a good job of merging them automatically; if they're not, it
marks the conflicts and lets you resolve them manually. None of that is
likely to be possible for binary files.
(If you can generate the binary files from an editable text file, that
solves problem, but that's not always possible.)
[...]
> Explain to me again how version control, _particularly_ git, is useful
> for a stand-alone programmer who has the discipline to make backups?
> I'm especially interested in a justification for either installing a
> whole new server, or trusting my (possibly proprietary, certainly
> personally written) code to another server in either "The Cloud" or the
> USA.
You don't have to set up a server. The repo, including all the history,
is stored under a single ".git" directory; you can make backups of that
if you like. Git *organizes* your backups, and lets you view your
project's history. For example, you can check out an older version of
your project, take a look at it, and then check out the current version
again, and it's likely to be *much* easier (and more space-efficient)
than retrieving the old version from a backup.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-12-05 09:05 -0500 |
| Message-ID | <oaC8y.177748$ij2.175837@fx08.iad> |
| In reply to | #77808 |
On 12/4/15 6:45 AM, Richard Bos wrote: > Explain to me again how version control, _particularly_ git, is useful > for a stand-alone programmer who has the discipline to make backups? > I'm especially interested in a justification for either installing a > whole new server, or trusting my (possibly proprietary, certainly > personally written) code to another server in either "The Cloud" or the > USA. > > Richard > First, Git doesn't need a server to operate (it can use servers as repositories, and they are sort of needed for a distributed team, but an individual doesn't need them). With SVN, the .svn directory stores control information to access the server and some options for that directory, in git, it IS the repository, possibly also storing information about remote repositories are. The difference between using Git and 'disciplined' backups is that since Git stored differences, not the whole source tree, you are much more apt to make MORE checkpoints while developing, since they are cheap. (Git does NOT replace doing real backups, especially when using just a local commit, you will still want to make off line backups of the project for safety).
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-05 17:42 +0000 |
| Message-ID | <slrnn668g5.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77808 |
(Disregarding other answers, which I didn't read properly.) On Fri, 2015-12-04, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> The other thing about svn is that it is that it works nicely and >> conveniently with a range of files - in particular, binary files are not >> an issue. git is great for pure programming source code - but less >> great for storing entire projects that may contain documentation in >> binary formats, CAD designs, and all sorts of other files. > > Wha... hold on, doesn't git know that we live in an interactive world > now? Graphics files have been an integral, unmissable part of > programming for, well, decades! And help files... OK, it's an open > source project, its main users don't know what the words "help file", > "manual" or "documentation" mean, but still, I think David Brown explained the quality of Git's documentation. This is the main reason I argue for treating documentation as source code: text files in version control, which you compile to whatever format is needed. It's also my main objection to word processors. It doesn't matter if they come from Microsoft or are free: if they don't fit in a version control workflow, their usefulness is very limited. > for those of us who have to > face _real_, non-geek, users, it'd be nice if it handled them. If it > handles only source code and not help files, I guarantee you that the > two _will_ get out of sync, which already happens far too often. Been there, done that, tried to change the process, failed. I see only one sane solution: keep the documentation's source in a text format. There are plenty to choose from: troff, LaTeX, Docbook, HTML, Markdown, Mediawiki, plain text ... >> > IMO, one first way to use Git could be to >> > - Ignore remotes; just do a 'git init' and do local version control >> > like with Walter F. Tichy's 1980s creation, rcs(1). >> >> That is okay for some initial testing, but I always recommend having a >> central repository. It means you are not dependent on the one PC for >> reliability, and can easily move the project around between different >> client machines. > > Erm... > >> > - Ignore branches; stick to master. >> >> Again, that's good to start with. But if you don't learn about >> branches, you lose much of the point of git (and can just as well stick >> to svn :-) ). > > Erm... > > Those are very nice for teams of programmers who need to work together > (or anti-together) on several branches of a large project. > > Explain to me again how version control, _particularly_ git, is useful > for a stand-alone programmer who has the discipline to make backups? > I'm especially interested in a justification for either installing a > whole new server, or trusting my (possibly proprietary, certainly > personally written) code to another server in either "The Cloud" or the > USA. There's nothing about Git that forces you to give up your privacy or freedom. It's unlike many other new-fangled things that way. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-06 22:23 +0100 |
| Message-ID | <n428ss$8uc$1@dont-email.me> |
| In reply to | #77901 |
On 05/12/15 18:42, Jorgen Grahn wrote: > (Disregarding other answers, which I didn't read properly.) > > On Fri, 2015-12-04, Richard Bos wrote: >> David Brown <david.brown@hesbynett.no> wrote: >> >>> The other thing about svn is that it is that it works nicely and >>> conveniently with a range of files - in particular, binary files are not >>> an issue. git is great for pure programming source code - but less >>> great for storing entire projects that may contain documentation in >>> binary formats, CAD designs, and all sorts of other files. >> >> Wha... hold on, doesn't git know that we live in an interactive world >> now? Graphics files have been an integral, unmissable part of >> programming for, well, decades! And help files... OK, it's an open >> source project, its main users don't know what the words "help file", >> "manual" or "documentation" mean, but still, > > I think David Brown explained the quality of Git's documentation. > > This is the main reason I argue for treating documentation as source > code: text files in version control, which you compile to whatever > format is needed. > > It's also my main objection to word processors. It doesn't matter if > they come from Microsoft or are free: if they don't fit in a version > control workflow, their usefulness is very limited. There is a balance to be struck between potentially conflicting requirements here. A text-based version-control friendly format is good. A commonly understood (within the appropriate working environment) format is good. Easy to use tools are good. Quality output is good. A stable, reliable format is good. The ability to view and edit the format with easily available, free or cheap, and cross-platform tools is good. You cannot necessarily meet all of these at the same time. That the format is reliable, stable, documented, and can be viewed and edited now and in the future is usually a fixed requirement. That rules out anything by Adobe or Microsoft. Text based formats such as LaTeX, docbook, and man pages are good for version control - but they can be hopeless from the viewpoint of having a variety of people work with the documents. In some environments, it is common for technical people to be happy working with such documents. But in many situations, it's a different matter - few programmers are familiar with them, and fewer still technical writers or other staff are fluent with them. There is no point in having a format that suits your tools well, but not your authors. Clearly simple formats, like plain text or plain text with a little markup, are fine for small document files (readmes, program notes, etc.). For documentation that is tightly coupled to the software, doxygen can be a good way of producing nice documentation, using text format source. LibreOffice is a better compromise for a lot of documentation. You can get basic comparisons between versions, or enable change tracking. The formats are documented and well supported, and you are free to use old or new versions of the software as you like - even if new LibreOffice versions were to have poor support for old formats, you can always get the old versions and use them. > >> for those of us who have to >> face _real_, non-geek, users, it'd be nice if it handled them. If it >> handles only source code and not help files, I guarantee you that the >> two _will_ get out of sync, which already happens far too often. > > Been there, done that, tried to change the process, failed. > > I see only one sane solution: keep the documentation's source in a > text format. There are plenty to choose from: troff, LaTeX, Docbook, > HTML, Markdown, Mediawiki, plain text ... > That's fine if you have suitably trained and motivated staff. In some environments, these will work - in many, they will be a non-starter. >>>> IMO, one first way to use Git could be to >>>> - Ignore remotes; just do a 'git init' and do local version control >>>> like with Walter F. Tichy's 1980s creation, rcs(1). >>> >>> That is okay for some initial testing, but I always recommend having a >>> central repository. It means you are not dependent on the one PC for >>> reliability, and can easily move the project around between different >>> client machines. >> >> Erm... >> >>>> - Ignore branches; stick to master. >>> >>> Again, that's good to start with. But if you don't learn about >>> branches, you lose much of the point of git (and can just as well stick >>> to svn :-) ). >> >> Erm... >> >> Those are very nice for teams of programmers who need to work together >> (or anti-together) on several branches of a large project. >> >> Explain to me again how version control, _particularly_ git, is useful >> for a stand-alone programmer who has the discipline to make backups? >> I'm especially interested in a justification for either installing a >> whole new server, or trusting my (possibly proprietary, certainly >> personally written) code to another server in either "The Cloud" or the >> USA. > > There's nothing about Git that forces you to give up your privacy or > freedom. It's unlike many other new-fangled things that way. > > /Jorgen >
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-07 21:59 +0000 |
| Message-ID | <slrnn6c09k.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77998 |
On Sun, 2015-12-06, David Brown wrote: > On 05/12/15 18:42, Jorgen Grahn wrote: ... >> On Fri, 2015-12-04, Richard Bos wrote: ... >>> for those of us who have to >>> face _real_, non-geek, users, it'd be nice if it handled them. If it >>> handles only source code and not help files, I guarantee you that the >>> two _will_ get out of sync, which already happens far too often. >> >> Been there, done that, tried to change the process, failed. >> >> I see only one sane solution: keep the documentation's source in a >> text format. There are plenty to choose from: troff, LaTeX, Docbook, >> HTML, Markdown, Mediawiki, plain text ... > > That's fine if you have suitably trained and motivated staff. In some > environments, these will work - in many, they will be a non-starter. If we limit it to people working on a software project, and producing documents closely related to the source code (the help files above, or a reference manual) I cannot imagine anyone being able to contribute (by writing C code, or performing non-trivial testing and so on) yet /unable/ to grok a simple text markup language. If that somehow isn't possible, and the documents need to track the code closely (e.g. it's a design document and needs to be branched when the source code is branched) then I prefer not to have any documentation at all. I've wasted too many weeks writing documents which noone would read, because they were always obsolete by design. As you can probably tell, I still get angry thinking about it. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-05 15:50 +0000 |
| Message-ID | <slrnn661uj.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77725 |
On Thu, 2015-12-03, David Brown wrote: > On 02/12/15 19:24, Jorgen Grahn wrote: >> On Wed, 2015-12-02, David Brown wrote: >>> On 02/12/15 12:52, BartC wrote: >> ... >>>> Thanks, but I prefer using my own tools as I've always have done. >> ... >>> If you want to use git on Windows, get TortoiseGit: >> ... >>> However, for someone new to version control systems, especially a >>> Windows user, I would not recommend git. I would suggest subversion >>> (with TortoiseSvn for windows). Git is significantly more powerful - >>> but also significantly more complex. Compared to having a bunch of >>> files in a directory, subversion gives you an extra dimension - it lets >>> you track changes over time. Git gives you two extra dimensions - time, >>> and also branches. So with a view to learning to walk before you try to >>> run, and because walking is often perfectly sufficient and a big >>> improvement over standing still, I suggest you learn about subversion. >>> And since subversion has always been a cross-platform solution from its >>> conception, it does not feel as alien on Windows. >> >> I don't think we can convince BartC to do anything he hasn't done in >> the past decades ... But in general: >> >> I think that unless you /know/ you'll be forced to use Subversion at >> some point, it's better to skip that step and go directly to Git. >> Because it's not really a /step/ -- svn and Git require that you think >> in different ways. And Git is a lot more polished: better documented, >> better practical features for everyday use. > > I disagree that git is more polished, or better documented, I don't have svn installed here for comparison, but when I used it for a month at work I was disappointed with the man pages (that's where I expect to find everyday documentation), and the options for viewing the history (e.g. no color diff, no word-diff). > or has > better practical features for everyday use. It certainly has features > that svn does not, and I appreciate what you say that git and svn > require different ways of thinking. But I still think that svn is > conceptually easier (you have one server, checkins go directly to the > server - you don't have the mix of local history and remotes), and a > smaller step from no version control - and I think it is easier to learn > git from svn than git from nothing, even though moving from svn to git > means some significant changes in the way you work. Ok, that's the core disagreement, then. > The other thing about svn is that it is that it works nicely and > conveniently with a range of files - in particular, binary files are not > an issue. git is great for pure programming source code - but less > great for storing entire projects that may contain documentation in > binary formats, CAD designs, and all sorts of other files. I don't understand -- how can binary files not be an issue? For example, how can you merge or diff two JPEG images? I haven't checked, but I assume both tools are equally good/bad at it. (Although I've heard Git has bad performance for large binary files.) >> IMO, one first way to use Git could be to >> - Ignore remotes; just do a 'git init' and do local version control >> like with Walter F. Tichy's 1980s creation, rcs(1). > > That is okay for some initial testing, but I always recommend having a > central repository. It means you are not dependent on the one PC for > reliability, and can easily move the project around between different > client machines. Ok, then it's rather easy to add a central repository and push to it now and then -- over ssh, for example. >> - Ignore branches; stick to master. > > Again, that's good to start with. But if you don't learn about > branches, you lose much of the point of git (and can just as well stick > to svn :-) ). To me, branching in the SVN sense isn't the main thing about Git; see below. >> - Focus on creating a sequence of well-defined and correct commits, >> and learn how to compare them. Learn how to use 'git rebase -i' >> and 'commit --amend' to make this happen. > > Yes, do plenty of trial-and-error and read some tutorials to get a few > useful, basic commands. Get used to them before doing anything "fancy". I get the feeling that you really want the basic SVN workflow, while I want one of the possible Git workflows. The thing I want most out of Git is having the result of my work split into neat, logical and correct changes, well documented and so on. So when I'm in the phase where I'm working by myself, I produce a lot of small commits, and now and then I go back to rearrange them, squash them together, fix bugs and so on. Rebase them on top of other people's changes. That was what my list above was supposed to give the newbie user: a "safety net" in the form of private commits, which she then rewrites into a more consise "story" meant to be public and permanent. I really miss that now whenever I work with CVS, SVN or ClearCase -- my checkins are often either too large, or too small, or contain stupid errors. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-05 18:17 +0100 |
| Message-ID | <n3v62a$fj3$1@dont-email.me> |
| In reply to | #77891 |
On 05/12/15 16:50, Jorgen Grahn wrote:
> On Thu, 2015-12-03, David Brown wrote:
>> On 02/12/15 19:24, Jorgen Grahn wrote:
>>> On Wed, 2015-12-02, David Brown wrote:
>>>> On 02/12/15 12:52, BartC wrote:
>>> ...
>>>>> Thanks, but I prefer using my own tools as I've always have done.
>>> ...
>>>> If you want to use git on Windows, get TortoiseGit:
>>> ...
>>>> However, for someone new to version control systems, especially a
>>>> Windows user, I would not recommend git. I would suggest subversion
>>>> (with TortoiseSvn for windows). Git is significantly more powerful -
>>>> but also significantly more complex. Compared to having a bunch of
>>>> files in a directory, subversion gives you an extra dimension - it lets
>>>> you track changes over time. Git gives you two extra dimensions - time,
>>>> and also branches. So with a view to learning to walk before you try to
>>>> run, and because walking is often perfectly sufficient and a big
>>>> improvement over standing still, I suggest you learn about subversion.
>>>> And since subversion has always been a cross-platform solution from its
>>>> conception, it does not feel as alien on Windows.
>>>
>>> I don't think we can convince BartC to do anything he hasn't done in
>>> the past decades ... But in general:
>>>
>>> I think that unless you /know/ you'll be forced to use Subversion at
>>> some point, it's better to skip that step and go directly to Git.
>>> Because it's not really a /step/ -- svn and Git require that you think
>>> in different ways. And Git is a lot more polished: better documented,
>>> better practical features for everyday use.
>>
>> I disagree that git is more polished, or better documented,
>
> I don't have svn installed here for comparison, but when I used it for
> a month at work I was disappointed with the man pages (that's where I
> expect to find everyday documentation), and the options for viewing
> the history (e.g. no color diff, no word-diff).
The main documentation is the subversion book (free online, or you can
buy the dead-tree version). I get most of my daily documentation needs
from "svn help" or a quick google, and have read a reasonable proportion
of the book over the years. Different projects use different formats
for their main documentation support - man pages are basically *nix
only, so cross-platform projects (like subversion) seldom put much
effort into the man pages.
As for coloured difference and history viewing, with svn you would
usually use gui tools like TortoiseSVN (Windows), RabbitSVN (Linux),
etc. Command line tools are fine for quick checks (and of course they
are great for commit, update, etc.), but when you are looking at bigger
changes it is much easier to use larger displays, scrollable windows,
etc. That applies equally to git and svn.
>
>> or has
>> better practical features for everyday use. It certainly has features
>> that svn does not, and I appreciate what you say that git and svn
>> require different ways of thinking. But I still think that svn is
>> conceptually easier (you have one server, checkins go directly to the
>> server - you don't have the mix of local history and remotes), and a
>> smaller step from no version control - and I think it is easier to learn
>> git from svn than git from nothing, even though moving from svn to git
>> means some significant changes in the way you work.
>
> Ok, that's the core disagreement, then.
Fair enough. We can educate each other when we are missing some
information, but it's rare for usenet posts to cause a change of opinion!
>
>> The other thing about svn is that it is that it works nicely and
>> conveniently with a range of files - in particular, binary files are not
>> an issue. git is great for pure programming source code - but less
>> great for storing entire projects that may contain documentation in
>> binary formats, CAD designs, and all sorts of other files.
>
> I don't understand -- how can binary files not be an issue? For
> example, how can you merge or diff two JPEG images?
You are of course limited in what you can do with binary files - but
with subversion (and client tools like TortoiseSVN, RabbitSVN, and other
software that has subversion support) you can get diffs or merges on
some binary formats. It is quite possible that you can do that too with
git - I haven't tried it out.
>
> I haven't checked, but I assume both tools are equally good/bad at it.
> (Although I've heard Git has bad performance for large binary files.)
There are a range of add-ons for git to make binary files less
inefficient and inconvenient. With subversion, you just check in your
binary files in exactly the same way as you handle text files. You
don't get all the features - you typically can't view differences or
merge them - but you don't need to jump through hoops to mark files as
binary.
>
>>> IMO, one first way to use Git could be to
>>> - Ignore remotes; just do a 'git init' and do local version control
>>> like with Walter F. Tichy's 1980s creation, rcs(1).
>>
>> That is okay for some initial testing, but I always recommend having a
>> central repository. It means you are not dependent on the one PC for
>> reliability, and can easily move the project around between different
>> client machines.
>
> Ok, then it's rather easy to add a central repository and push to it
> now and then -- over ssh, for example.
Indeed - that's the way I prefer to use git.
A key difference between git and subversion is that when you have a
central repository, git has your local repository as a step between the
working directory and the central repository. This is both a blessing
and a curse - it makes git much more flexible, and lets you track
changes underway while keeping the central shared repository clean. But
it also makes the model more complex, harder to learn, and confusing for
new users ("I checked in the changes for the new version". "No you
didn't - I don't see them on the server". "Yes I did, I used git
commit"...)
>
>>> - Ignore branches; stick to master.
>>
>> Again, that's good to start with. But if you don't learn about
>> branches, you lose much of the point of git (and can just as well stick
>> to svn :-) ).
>
> To me, branching in the SVN sense isn't the main thing about Git; see
> below.
>
>>> - Focus on creating a sequence of well-defined and correct commits,
>>> and learn how to compare them. Learn how to use 'git rebase -i'
>>> and 'commit --amend' to make this happen.
>>
>> Yes, do plenty of trial-and-error and read some tutorials to get a few
>> useful, basic commands. Get used to them before doing anything "fancy".
>
> I get the feeling that you really want the basic SVN workflow, while I
> want one of the possible Git workflows.
>
> The thing I want most out of Git is having the result of my work split
> into neat, logical and correct changes, well documented and so on. So
> when I'm in the phase where I'm working by myself, I produce a lot of
> small commits, and now and then I go back to rearrange them, squash
> them together, fix bugs and so on. Rebase them on top of other
> people's changes.
>
> That was what my list above was supposed to give the newbie user: a
> "safety net" in the form of private commits, which she then rewrites
> into a more consise "story" meant to be public and permanent.
>
> I really miss that now whenever I work with CVS, SVN or ClearCase --
> my checkins are often either too large, or too small, or contain
> stupid errors.
>
I agree that git supports a "lots of small checkins" workflow better
than subversion. For the kind of use you are looking for, git is a
better choice than subversion. All I am saying is that subversion has
advantages over git in other areas, and can be a better choice in such
cases.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-06 10:01 +0000 |
| Message-ID | <slrnn681si.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77899 |
On Sat, 2015-12-05, David Brown wrote:
> On 05/12/15 16:50, Jorgen Grahn wrote:
>> On Thu, 2015-12-03, David Brown wrote:
>>> On 02/12/15 19:24, Jorgen Grahn wrote:
>>>> On Wed, 2015-12-02, David Brown wrote:
>>>>> On 02/12/15 12:52, BartC wrote:
>>>> ...
>>>>>> Thanks, but I prefer using my own tools as I've always have done.
>>>> ...
>>>>> If you want to use git on Windows, get TortoiseGit:
>>>> ...
>>>>> However, for someone new to version control systems, especially a
>>>>> Windows user, I would not recommend git. I would suggest subversion
>>>>> (with TortoiseSvn for windows). Git is significantly more powerful -
>>>>> but also significantly more complex. Compared to having a bunch of
>>>>> files in a directory, subversion gives you an extra dimension - it lets
>>>>> you track changes over time. Git gives you two extra dimensions - time,
>>>>> and also branches. So with a view to learning to walk before you try to
>>>>> run, and because walking is often perfectly sufficient and a big
>>>>> improvement over standing still, I suggest you learn about subversion.
>>>>> And since subversion has always been a cross-platform solution from its
>>>>> conception, it does not feel as alien on Windows.
>>>>
>>>> I don't think we can convince BartC to do anything he hasn't done in
>>>> the past decades ... But in general:
>>>>
>>>> I think that unless you /know/ you'll be forced to use Subversion at
>>>> some point, it's better to skip that step and go directly to Git.
>>>> Because it's not really a /step/ -- svn and Git require that you think
>>>> in different ways. And Git is a lot more polished: better documented,
>>>> better practical features for everyday use.
>>>
>>> I disagree that git is more polished, or better documented,
>>
>> I don't have svn installed here for comparison, but when I used it for
>> a month at work I was disappointed with the man pages (that's where I
>> expect to find everyday documentation), and the options for viewing
>> the history (e.g. no color diff, no word-diff).
>
> The main documentation is the subversion book (free online, or you can
> buy the dead-tree version). I get most of my daily documentation needs
> from "svn help" or a quick google, and have read a reasonable proportion
> of the book over the years. Different projects use different formats
> for their main documentation support - man pages are basically *nix
> only, so cross-platform projects (like subversion) seldom put much
> effort into the man pages.
I haven't seen a lot of software without decent man pages ... but I'm
on Debian Linux, but that project tends to write man pages themselves
if they're missing upstream.
It /is/ possible to adapt to the platform's documentation conventions,
even if the software is cross-platform.
> As for coloured difference and history viewing, with svn you would
> usually use gui tools like TortoiseSVN (Windows), RabbitSVN (Linux),
> etc. Command line tools are fine for quick checks (and of course they
> are great for commit, update, etc.), but when you are looking at bigger
> changes it is much easier to use larger displays, scrollable windows,
> etc. That applies equally to git and svn.
(My displays are large and my terminal windows are scrollable. Noone
uses VT100 terminals these days.)
The command line versus GUI argument. I'm in the command line camp,
and I could write a long, boring essay about that ... anyway, IMO Git
supports me very well there -- it's the "polished" aspect I was
talking about.
But if you say SVN focuses on GUI use, that explains what I've seen:
the svn command-line looked as if it was minimalistic and really
wanted a frontend of some kind.
I can believe that GUI shells for SVN are better than those for Git.
The only one I've seen (the one that comes with Git) seems to mimic
the command line quite closely; it looks just like a clickable version
of 'git log --oneline'. I know sensible people who use it, but
personally I can't see the added value.
>>> or has
>>> better practical features for everyday use. It certainly has features
>>> that svn does not, and I appreciate what you say that git and svn
>>> require different ways of thinking. But I still think that svn is
>>> conceptually easier (you have one server, checkins go directly to the
>>> server - you don't have the mix of local history and remotes), and a
>>> smaller step from no version control - and I think it is easier to learn
>>> git from svn than git from nothing, even though moving from svn to git
>>> means some significant changes in the way you work.
>>
>> Ok, that's the core disagreement, then.
>
> Fair enough. We can educate each other when we are missing some
> information, but it's rare for usenet posts to cause a change of opinion!
Yes, let's aim for understanding, not a change.
>>> The other thing about svn is that it is that it works nicely and
>>> conveniently with a range of files - in particular, binary files are not
>>> an issue. git is great for pure programming source code - but less
>>> great for storing entire projects that may contain documentation in
>>> binary formats, CAD designs, and all sorts of other files.
>>
>> I don't understand -- how can binary files not be an issue? For
>> example, how can you merge or diff two JPEG images?
>
> You are of course limited in what you can do with binary files - but
> with subversion (and client tools like TortoiseSVN, RabbitSVN, and other
> software that has subversion support) you can get diffs or merges on
> some binary formats. It is quite possible that you can do that too with
> git - I haven't tried it out.
Me neither, but I think those hooks exist.
>> I haven't checked, but I assume both tools are equally good/bad at it.
>> (Although I've heard Git has bad performance for large binary files.)
>
> There are a range of add-ons for git to make binary files less
> inefficient and inconvenient. With subversion, you just check in your
> binary files in exactly the same way as you handle text files. You
> don't get all the features - you typically can't view differences or
> merge them - but you don't need to jump through hoops to mark files as
> binary.
You don't have to do that with Git either. I have a repository with a
300 MB of bitmap images in it, and that seems to work alright.
It's unclear to me at which point Git starts to behave badly with
binary files.
>>>> IMO, one first way to use Git could be to
>>>> - Ignore remotes; just do a 'git init' and do local version control
>>>> like with Walter F. Tichy's 1980s creation, rcs(1).
>>>
>>> That is okay for some initial testing, but I always recommend having a
>>> central repository. It means you are not dependent on the one PC for
>>> reliability, and can easily move the project around between different
>>> client machines.
>>
>> Ok, then it's rather easy to add a central repository and push to it
>> now and then -- over ssh, for example.
>
> Indeed - that's the way I prefer to use git.
>
> A key difference between git and subversion is that when you have a
> central repository, git has your local repository as a step between the
> working directory and the central repository. This is both a blessing
> and a curse - it makes git much more flexible, and lets you track
> changes underway while keeping the central shared repository clean. But
> it also makes the model more complex, harder to learn, and confusing for
> new users ("I checked in the changes for the new version". "No you
> didn't - I don't see them on the server". "Yes I did, I used git
> commit"...)
That is true, and it's the reason I haven't migrated the CVS
repositories I share with my brother. He can understand the
workflow:
- edit file
- cvs up
- fix conflicts
- cvs ci with a descriptive message
But Git would add another dimension, and I'm not sure he'd want to
learn to deal with it.
Since I started using Git, I got problems with that too. I have
dozens of different repositories; which of them contain changes which
should be pushed?
...
> I agree that git supports a "lots of small checkins" workflow better
> than subversion. For the kind of use you are looking for, git is a
> better choice than subversion. All I am saying is that subversion has
> advantages over git in other areas, and can be a better choice in such
> cases.
Yes; it's a matter of what properties you value the most.
I think the reason I fell in love with "lots of small checkins"
followed by a cleaning up phase is this: I've worked a lot in large
projects, and I've always been frustrated with the lack of metadata
about changes. I hope that Git, properly used, means that when a
sister team delivers their latest feature, I can read the commit
messages and the diffs, and quickly get a decent picture of what
they've done and how it affects me.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-12-06 03:05 -0800 |
| Message-ID | <07cfc60c-f1ec-46e5-b8f7-3fe837116a6a@googlegroups.com> |
| In reply to | #77954 |
On Sunday, 6 December 2015 12:02:17 UTC+2, Jorgen Grahn wrote: > On Sat, 2015-12-05, David Brown wrote: > > > > There are a range of add-ons for git to make binary files less > > inefficient and inconvenient. With subversion, you just check in your > > binary files in exactly the same way as you handle text files. You > > don't get all the features - you typically can't view differences or > > merge them - but you don't need to jump through hoops to mark files as > > binary. > > You don't have to do that with Git either. I have a repository with a > 300 MB of bitmap images in it, and that seems to work alright. > > It's unclear to me at which point Git starts to behave badly with > binary files. The binary files (typically some multimedia) do not change too often and so are fine even without special tricks to conserve storage. The cases that I have observed were what I consider as a clear misuse of repository. For example continuous integration did make nightly build, updated version numbers, zipped together deployment package, pushed to central repository and tagged the change. After few months the repository did grow large and things became sluggish. Moving the binaries out from repository to file server where each deployment package had version and date in its name. It was simpler for all sides and also restored the performance of repository. Similar problem I have seen with generated documentation (PDF) and large generated XML files. XML is actually text but it seems to be maliciously designed for to achieve that diffing algorithms go nuts. People involved should think a bit and not abuse repositories by putting computer-generated spam in those. However as long it is like in https://xkcd.com/1597/ it does happen. ;)
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web