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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-06 04:07 -0800 |
| Message-ID | <04bd2b23-1eed-4b2d-a81c-7fe1a7524f00@googlegroups.com> |
| In reply to | #77958 |
On Sunday, December 6, 2015 at 11:05:27 AM UTC, Öö Tiib wrote: > 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. > Binary resources like images are OK, as long as updating is relatively rare. That means that things like "project" or "workspace" files, which change on every edit-compile-test cycle, are not suitable for the 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. > This is the problem. git obviously can't distinguish human-generated from non-human generated text. But the automatic merge algorithms don't work well on non-human generated text. A hand written xml file will be fine, but an automatically generated one can have distant, hard to recognise dependencies that the xml generator / reader just spits out. If a merge breaks, it's then impossible to repair.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-12-06 04:37 -0800 |
| Message-ID | <e70c88eb-2c9f-4cdf-8dfb-47d67982561d@googlegroups.com> |
| In reply to | #77963 |
On Sunday, 6 December 2015 14:08:03 UTC+2, Malcolm McLean wrote: > On Sunday, December 6, 2015 at 11:05:27 AM UTC, Öö Tiib wrote: > > 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. > > > Binary resources like images are OK, as long as updating is relatively rare. > That means that things like "project" or "workspace" files, which change on > every edit-compile-test cycle, are not suitable for the repository. What you mean by "project" and "workspace" files? Where these are binary? These are typically text files regardless if people use IDEs or don't. > > > > 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. > > > This is the problem. git obviously can't distinguish human-generated from > non-human generated text. But the automatic merge algorithms don't work > well on non-human generated text. A hand written xml file will be fine, > but an automatically generated one can have distant, hard to recognise > dependencies that the xml generator / reader just spits out. If a merge > breaks, it's then impossible to repair. The diff tools that are confused by XML will AFAIK refuse to merge several changes automatically. On all cases that I have seen it has been low quality manual merge that resulted with broken file. It is possible to revert the broken file to previous version and redo the changes. It can be rather annoying with large XML file but "impossible" is overstatement.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-06 05:05 -0800 |
| Message-ID | <ede15f2d-ce58-4fae-9a48-357469e6399e@googlegroups.com> |
| In reply to | #77964 |
On Sunday, December 6, 2015 at 12:37:47 PM UTC, Öö Tiib wrote: > On Sunday, 6 December 2015 14:08:03 UTC+2, Malcolm McLean wrote: > > > Binary resources like images are OK, as long as updating is relatively rare. > > That means that things like "project" or "workspace" files, which change on > > every edit-compile-test cycle, are not suitable for the repository. > > What you mean by "project" and "workspace" files? Where these are binary? > These are typically text files regardless if people use IDEs or don't. > IDEs typically have various bits and bobs which aren't strictly source or "resources", and which help the IDE keep track of the program. They're termed things like "project files", but the terminology varies from system to system. Some of them might be technically text formats. > > > > > > 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. > > > > > This is the problem. git obviously can't distinguish human-generated from > > non-human generated text. But the automatic merge algorithms don't work > > well on non-human generated text. A hand written xml file will be fine, > > but an automatically generated one can have distant, hard to recognise > > dependencies that the xml generator / reader just spits out. If a merge > > breaks, it's then impossible to repair. > > The diff tools that are confused by XML will AFAIK refuse to merge > several changes automatically. On all cases that I have seen it has > been low quality manual merge that resulted with broken file. It is > possible to revert the broken file to previous version and redo the > changes. It can be rather annoying with large XML file but "impossible" > is overstatement. > A merge fails when either git;s automatic merge tool cannot determine how to merge two files. e.g. if the base version is char *name = "Fred"; and version a has char *name = "Joe"; and version b has char *name = "Bloggs"; what should the merge be? Git has no way of knowing, and it flags up a merge conflict. To a human, the names are meaningful - Joe Bloggs is a common placeholder name, and if name can hold first name + surname, it's likely that "Joe Bloggs" best preserves the intent of both modifiers. But we can also have this situation. Base char *name = "Joe Bloggs"; version a char *fullname = "Joe Bloggs"; version b char *name = "Joe"; git will likely merge this as char *fullname = "Joe"; which is clearly wrong. So that's another type of merge fail. As long the text is human-generated, a human who understands what is being communicated can usually patch it up correctly. But when the C source (or XML) isn't human generated, you can't do that. Humans seldom do low quality manual merges of human-generated text. The human brain's language processing algorithm is amazingly sophisticated.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-06 12:19 -0800 |
| Message-ID | <lnsi3fpbx1.fsf@kst-u.example.com> |
| In reply to | #77975 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> But we can also have this situation.
>
> Base
>
> char *name = "Joe Bloggs";
>
> version a
>
> char *fullname = "Joe Bloggs";
>
> version b
>
> char *name = "Joe";
>
> git will likely merge this as
>
> char *fullname = "Joe";
>
> which is clearly wrong. So that's another type of merge fail.
No, git reports this as a merge conflict, and lets you resolve it
manually (I just tried it).
If I'm not mistaken, git's comparison and merging algorithms are
line-based. It will see that the line has changed in both branches;
it won't see the similarities within the line.
If you split the declaration into multiple lines, so the variable name
and the initial value are separated, git will do an automatic merge.
The message I got on the merge was:
Fast-forwarding to: a
Trying simple merge with b
Simple merge did not work, trying automatic merge.
Auto-merging foo.c
Merge made by the 'octopus' strategy.
In my experience, git is very good at doing automatic merging in most
cases, and at determining when it should let the user merge manually.
But of course it's not perfect.
[...]
--
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 | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-06 13:59 +0000 |
| Message-ID | <slrnn68fq4.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77958 |
On Sun, 2015-12-06, Öö Tiib wrote: > On Sunday, 6 December 2015 12:02:17 UTC+2, Jorgen Grahn wrote: ... >> 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. It's unclear to me why people put generated things in version control, but it seems to happen over and over again. I've certainly seen it myself. > 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. One could perhaps use a tool like xmllint to re-indent it without changing the semantics. But it would be better if people who write tools to generate data asked themselves a few questions: - How can I support users collaborating using my tool? - Will someone want to put the output from my program under version control? - Can I do something to make that easier? It's weird that this fails so often, because surely those people use version control themselves! /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-06 06:09 -0800 |
| Message-ID | <77027068-310f-409d-896f-31fd21307761@googlegroups.com> |
| In reply to | #77981 |
On Sunday, December 6, 2015 at 1:59:43 PM UTC, Jorgen Grahn wrote: > On Sun, 2015-12-06, 嘱 Tiib wrote: > > It's unclear to me why people put generated things in version control, > but it seems to happen over and over again. I've certainly seen it > myself. > Because if you've got a long tool chain, it can become rather difficult to go to a previous version. With git, you have to manually delete all the intermediaries, then re-run the image generator which generates a resource script which generates C source which generates a Perl script which generates more C source which goes into the final product.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-12-06 07:30 -0800 |
| Message-ID | <932de71d-400d-4ad1-a955-21ba3174336f@googlegroups.com> |
| In reply to | #77982 |
On Sunday, 6 December 2015 16:09:20 UTC+2, Malcolm McLean wrote: > On Sunday, December 6, 2015 at 1:59:43 PM UTC, Jorgen Grahn wrote: > > On Sun, 2015-12-06, Öö Tiib wrote: > > > > It's unclear to me why people put generated things in version control, > > but it seems to happen over and over again. I've certainly seen it > > myself. > > > Because if you've got a long tool chain, it can become rather difficult to > go to a previous version. With git, you have to manually delete all the > intermediaries, then re-run the image generator which generates a > resource script which generates C source which generates a Perl > script which generates more C source which goes into the final product. Where work is done like that? I thought most do not delete anything manually nor run generators manually. Software developers typically automate their own tool-chain as first thing. When people want to clean intermediate files from command line they type something like "make clean". When people do it from IDE then they choose something like "Build"->"Clean All" from menu or choose accelerator combination for it from keyboard. It has been like that all the decades that I can remember.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-06 18:55 +0000 |
| Message-ID | <slrnn6914c.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77985 |
On Sun, 2015-12-06, Öö Tiib wrote: > On Sunday, 6 December 2015 16:09:20 UTC+2, Malcolm McLean wrote: >> On Sunday, December 6, 2015 at 1:59:43 PM UTC, Jorgen Grahn wrote: >> > On Sun, 2015-12-06, Öö Tiib wrote: >> > >> > It's unclear to me why people put generated things in version control, >> > but it seems to happen over and over again. I've certainly seen it >> > myself. >> > >> Because if you've got a long tool chain, it can become rather difficult to >> go to a previous version. With git, you have to manually delete all the >> intermediaries, then re-run the image generator which generates a >> resource script which generates C source which generates a Perl >> script which generates more C source which goes into the final product. > > Where work is done like that? I thought most do not delete anything > manually nor run generators manually. Software developers typically > automate their own tool-chain as first thing. > > When people want to clean intermediate files from command line they > type something like "make clean". You don't even have to do that: check out an older version from Git, and type "make". If something needs to be rebuilt, it will be rebuilt. Saves some time on larger projects. > When people do it from IDE then they choose something like > "Build"->"Clean All" from menu or choose accelerator combination for > it from keyboard. > > It has been like that all the decades that I can remember. It's worse with older version control tools like CVS, because they treat file timestamps differently. If you go back in time with CVS and don't do "make clean", you risk generating a bad build. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-06 12:23 -0800 |
| Message-ID | <lnk2orpbrf.fsf@kst-u.example.com> |
| In reply to | #77982 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, December 6, 2015 at 1:59:43 PM UTC, Jorgen Grahn wrote:
>> On Sun, 2015-12-06, 嘱 Tiib wrote:
>> It's unclear to me why people put generated things in version control,
>> but it seems to happen over and over again. I've certainly seen it
>> myself.
>>
> Because if you've got a long tool chain, it can become rather difficult to
> go to a previous version. With git, you have to manually delete all the
> intermediaries, then re-run the image generator which generates a
> resource script which generates C source which generates a Perl
> script which generates more C source which goes into the final product.
make clean ; make
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-06 12:22 -0800 |
| Message-ID | <lnoae3pbss.fsf@kst-u.example.com> |
| In reply to | #77981 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
[...]
> It's unclear to me why people put generated things in version control,
> but it seems to happen over and over again. I've certainly seen it
> myself.
[...]
I prefer not to do this, but I've recently had a case where it
made sense.
A project had documentation that was generated from an input file
in Markdown format. The Makefile created files in man page and
PDF formats, but it required tools that other users might not
have installed, so I added the generated files to the repository.
It does make things a little more complicated, but it makes the
human-readable documentation more easily available to other users.
--
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 | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-06 21:06 +0000 |
| Message-ID | <slrnn698r8.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77994 |
On Sun, 2015-12-06, Keith Thompson wrote: > Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > [...] >> It's unclear to me why people put generated things in version control, >> but it seems to happen over and over again. I've certainly seen it >> myself. > [...] > > I prefer not to do this, but I've recently had a case where it > made sense. > > A project had documentation that was generated from an input file > in Markdown format. The Makefile created files in man page and > PDF formats, but it required tools that other users might not > have installed, so I added the generated files to the repository. > It does make things a little more complicated, but it makes the > human-readable documentation more easily available to other users. Ok, that use case. You're right. Another fairly harmless case is when software is built using Autotools, but you ship the generated configure script and Makefile. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-12-05 13:14 -0600 |
| Message-ID | <n3vcl5$aih$1@dont-email.me> |
| In reply to | #77891 |
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). > >> 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. > So there's a sort of second dimension to commits. Nice! > 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. > That's extremely useful. > 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 am thinking that with SVN and CVS, you have to rebase ( svn update and whatever it was in CVS ) before committing. > /Jorgen > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-06 10:09 +0000 |
| Message-ID | <slrnn682am.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77909 |
On Sat, 2015-12-05, Les Cargill wrote: > Jorgen Grahn wrote: ... >> 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 am thinking that with SVN and CVS, you have to rebase ( svn update > and whatever it was in CVS ) before committing. It's 'cvs update', same as SVN. You have to do that with Git, too. If you're working on the local branch 'master', producing a few commits, and other commits arrive on 'origin/master', you typically do a "git rebase" to adapt to those changes. But you can delay that step if you're in the middle of something. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2015-12-03 06:15 -0800 |
| Message-ID | <1f7b6852-b31f-463f-b19c-4baae2c44e3e@googlegroups.com> |
| In reply to | #77646 |
On Wednesday, 2 December 2015 18:24:41 UTC, Jorgen Grahn wrote: Alternatively <https://xkcd.com/1597/>
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2015-12-02 08:28 -0700 |
| Message-ID | <1bh9k0dg4w.fsf@pfeifferfamily.net> |
| In reply to | #77603 |
Philip Lantz <prl@canterey.us> writes: > BartC wrote: >> Jorgen Grahn wrote: >> > Richard Heathfield wrote: >> >> Joe Pfeiffer wrote: >> >>> >> >>> I like [ // comments ] for two reasons -- >> >>> >> >>> I don't have to look for the end of a comment block. It's just a block >> >>> of // >> >> >> >> Syntax colouring? :-) >> >> >> >>> >> >>> If I'm in the throes of debugging I can comment out a bunch of code with >> >>> /* */ without a comment throwing in a monkey wrench. >> >> >> >> #if 0 >> >> >> >> #endif >> > >> > Or often better, use the version control system and just delete the >> > code. >> >> Better? I comment and uncomment lines /all the time/ while developing >> code, sometimes several times a minute. I use single-key commands in my >> editor to instantly comment/uncomment the current line then move on to >> the next. With key repeat it can do blocks of code at 20 lines per >> second. Commented blocks can be nested. >> >> I can compare commented/uncommented lines instantly. One common use is >> to comment out the real code and use temporary test code to try >> something new; I don't want to delete working code! >> >> How long would a version system take to do that with trivial blocks of >> code? Apart which which, I might in the middle move on to work on >> another part of the application, then come back to this bit. How to undo >> the obvious comments without undoing anything else? >> >> (I've never used version control but it sounds like a very big >> sledgehammer to for what we're talking about. Using #if 0 is just a >> standard hammer for the same job!) > > It is a big hammer for this kind of job, but if you are using it > anyway for the things that it is needed for (which I highly > recommend), it is there ready and waiting to do these sorts of > tasks also. > > Git can do all the things you mention above in an instant (once you > learn the commands, of course). And you never need to worry about > deleting working code, either accidentally or because you thought > you discovered a better way and then changed your mind later. It's > always there in the git repository (assuming you commit frequently > enough). I use svn for version control on my own projects, but I prefer to wait to commit code until I've got something new working. I really don't want 100 commits with "removed lines 97 and 98 to see if that's where the bug is", "put 97 and 98 back in, took out 94-96" log entries. The nice thing for me about commenting out blocks of code with /* */ is that doesn't appear anywhere else in my code. #if and #endif is likely to.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-02 09:01 -0800 |
| Message-ID | <ln4mg0u6mb.fsf@kst-u.example.com> |
| In reply to | #77624 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
[...]
> I use svn for version control on my own projects, but I prefer to wait
> to commit code until I've got something new working. I really don't
> want 100 commits with "removed lines 97 and 98 to see if that's where
> the bug is", "put 97 and 98 back in, took out 94-96" log entries.
Git is very good at handling branches. (SVN, as I understand it,
doesn't support branches directly; there are conventions that
involve making copies of the entire source tree, which SVN is able
to store efficiently.)
A common Git workflow is to develop a feature or bug fix on its
own branch, with frequent checkins, even of non-working code.
Once you've got the code working, you can merge it into the main
branch (usually called "master") and, if you like, squash multiple
commits into one to keep the history clean. You can delete the
feature branch once it's been merged -- or you can just leave it
in place in case you want to see the detailed history later.
And you don't need a network connection to use Git. You work with
a local clone of the entire repository, including all its history.
If there's a master repo, you interact with it only when you need to.
Changes you make in your own repo are not shared unless you share
them.
The biggest drawback of Git, IMHO, is that its underlying data model is
rather complex *and* that complexity is visible in the user interface.
On the other hand, you can learn a few simple commands and start using
it almost immediately. Complex workflows can be confusing, but simple
workflows (say, a linear sequence of updates with no branches) are
straightforward.
[...]
--
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 | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-02 21:52 +0000 |
| Message-ID | <slrnn5uq14.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77634 |
On Wed, 2015-12-02, Keith Thompson wrote: > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: > [...] >> I use svn for version control on my own projects, but I prefer to wait >> to commit code until I've got something new working. I really don't >> want 100 commits with "removed lines 97 and 98 to see if that's where >> the bug is", "put 97 and 98 back in, took out 94-96" log entries. > > Git is very good at handling branches. And, since he brings it up above, it's very good at creating commits which you discard, or squash into one, or move around, while they're still private. > (SVN, as I understand it, > doesn't support branches directly; there are conventions that > involve making copies of the entire source tree, which SVN is able > to store efficiently.) If that's true, then it's ironic: CVS has poor branching support, and that was the primary flaw that SVN was supposed to fix. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-02 16:55 -0800 |
| Message-ID | <lnmvtsqrjw.fsf@kst-u.example.com> |
| In reply to | #77670 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Wed, 2015-12-02, Keith Thompson wrote:
[...]
>> (SVN, as I understand it,
>> doesn't support branches directly; there are conventions that
>> involve making copies of the entire source tree, which SVN is able
>> to store efficiently.)
>
> If that's true, then it's ironic: CVS has poor branching support, and
> that was the primary flaw that SVN was supposed to fix.
An SVN advocate (which I'm not, particularly) would probably say that
SVN has perfectly good branching support, it's just implemented in a
somewhat unusual way.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-03 13:11 +0100 |
| Message-ID | <n3pbdk$gli$1@dont-email.me> |
| In reply to | #77686 |
On 03/12/15 01:55, Keith Thompson wrote: > Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >> On Wed, 2015-12-02, Keith Thompson wrote: > [...] >>> (SVN, as I understand it, >>> doesn't support branches directly; there are conventions that >>> involve making copies of the entire source tree, which SVN is able >>> to store efficiently.) >> >> If that's true, then it's ironic: CVS has poor branching support, and >> that was the primary flaw that SVN was supposed to fix. > > An SVN advocate (which I'm not, particularly) would probably say that > SVN has perfectly good branching support, it's just implemented in a > somewhat unusual way. > I am a happy svn users, though I am also happy to say that git is a better choice in many cases. git has a more integrated and convenient branch model - git users branch all the time. svn has branches, but they are a little different from git branches, and certainly not as fast and convenient to use git's - so svn users use them much less often. But one thing to remember here is that branching (and in particular, merging and merge tracking) has improved in later versions of svn - before you believe anything anyone tells you about poor branching in svn, make sure they are not using an ancient version of svn. SVN was designed to fix a great number of flaws (or at least, perceived flaws) in CVS. As far as I know, branching was not the main issue. To me, the main issue is that CVS works file-by-file, while SVN works as transactions on the whole repository.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-03 23:21 +0000 |
| Message-ID | <slrnn61jjh.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77728 |
On Thu, 2015-12-03, David Brown wrote: > On 03/12/15 01:55, Keith Thompson wrote: >> Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >>> On Wed, 2015-12-02, Keith Thompson wrote: >> [...] >>>> (SVN, as I understand it, >>>> doesn't support branches directly; there are conventions that >>>> involve making copies of the entire source tree, which SVN is able >>>> to store efficiently.) >>> >>> If that's true, then it's ironic: CVS has poor branching support, and >>> that was the primary flaw that SVN was supposed to fix. ... > SVN was designed to fix a great number of flaws (or at least, perceived > flaws) in CVS. As far as I know, branching was not the main issue. To > me, the main issue is that CVS works file-by-file, while SVN works as > transactions on the whole repository. A focus on branching was how I percieved it back then, but it might have been a) The people I was talking to (on comp.software.config-mgmt). b) Besides CVS, I was used to ClearCase which had good branching support (but very different from Git's) which I used all the time. That was the main flaw in CVS, as far as I was concerned. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web