Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.vms > #58112 > unrolled thread
| Started by | "Paul Richards" <paulrichards@iinet.net.au> |
|---|---|
| First post | 2016-06-08 18:18 -0500 |
| Last post | 2016-06-10 08:26 -0500 |
| Articles | 20 on this page of 150 — 23 participants |
Back to article view | Back to comp.os.vms
Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-08 18:18 -0500
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-08 19:39 -0400
Re: Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-08 20:28 -0500
Re: Where to locate software "Bill Pedersen" <pedersen@ccsscorp.com> - 2016-06-08 19:40 -0400
Re: Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-08 20:30 -0500
Re: Where to locate software "Bill Pedersen" <pedersen@ccsscorp.com> - 2016-06-08 22:24 -0400
Re: Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-08 22:57 -0500
Re: Where to locate software Steven Schweda <sms.antinode@gmail.com> - 2016-06-08 17:02 -0700
Re: Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-08 20:31 -0500
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-08 21:53 -0700
Re: Where to locate software Steven Schweda <sms.antinode@gmail.com> - 2016-06-08 22:19 -0700
Re: Where to locate software Richard Levitte <richard@levitte.org> - 2016-06-09 02:47 -0700
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-09 13:39 -0700
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 08:42 -0400
Re: Where to locate software Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-09 14:58 +0200
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 10:27 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 11:33 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 11:43 -0400
Re: Where to locate software johnwallace4@yahoo.co.uk - 2016-06-09 09:19 -0700
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 13:13 -0400
Re: Where to locate software Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-09 18:58 +0000
Re: Where to locate software Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-09 18:59 +0000
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 22:01 -0400
Re: VMS FAQ (was Re: Where to locate software) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-10 10:58 -0400
Re: VMS FAQ (was Re: Where to locate software) Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-10 16:50 +0000
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-09 13:28 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 22:06 -0400
Re: Where to locate software VAXman- @SendSpamHere.ORG - 2016-06-09 13:58 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 11:16 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-09 14:46 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 12:43 -0400
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-09 13:50 -0700
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 22:20 -0400
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-10 11:11 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-10 11:56 -0400
Re: Where to locate software johnwallace4@yahoo.co.uk - 2016-06-10 10:19 -0700
Re: Where to locate software Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-10 18:03 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-10 15:59 -0400
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-13 09:02 -0400
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-13 16:34 +0200
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-10 16:53 -0400
Re: Where to locate software Hans Vlems <hvlems@freenet.de> - 2016-06-11 00:27 -0700
Re: Where to locate software johnwallace4@yahoo.co.uk - 2016-06-11 01:37 -0700
Re: Where to locate software Hans Vlems <hvlems@freenet.de> - 2016-06-11 03:21 -0700
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-11 22:02 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-11 22:27 -0400
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-13 09:05 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-10 16:13 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-10 15:50 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-10 20:54 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-10 17:47 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-11 01:59 +0000
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-10 19:13 -0700
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-11 03:01 +0000
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-10 22:47 -0700
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-11 12:45 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-11 15:02 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 02:07 +0000
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-11 22:05 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 04:17 +0000
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-11 03:09 +0000
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-10 23:39 -0400
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-10 22:44 -0700
Re: Where to locate software johnwallace4@yahoo.co.uk - 2016-06-11 01:42 -0700
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-11 18:25 -0700
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-11 11:15 +0200
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-11 13:44 -0400
Re: Where to locate software johnwallace4@yahoo.co.uk - 2016-06-11 11:54 -0700
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-11 15:23 -0400
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-11 18:28 -0700
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-11 22:38 -0400
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-12 00:59 -0700
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 14:09 +0000
devops / source control - (Was: Where to locate software) "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-12 10:43 -0500
Re: devops / source control - (Was: Where to locate software) "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-12 11:08 -0500
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-12 12:53 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 17:31 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-12 15:23 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 20:28 +0000
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-12 17:49 -0700
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-13 13:02 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-13 09:40 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-13 14:33 +0000
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-13 16:20 +0200
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-13 15:12 +0000
Re: Where to locate software RobertsonEricW <robertsonericw@netzero.net> - 2016-06-13 08:55 -0700
Re: Where to locate software John Reagan <xyzzy1959@gmail.com> - 2016-06-13 09:07 -0700
Re: Where to locate software "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-16 15:16 -0500
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-16 20:25 -0700
Re: Where to locate software Richard Levitte <richard@levitte.org> - 2016-06-16 23:24 -0700
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-19 06:21 +0200
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-19 06:08 +0200
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-18 21:52 -0700
Re: Where to locate software "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-19 19:17 -0500
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-13 15:03 -0700
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-13 09:08 -0400
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-13 21:05 -0500
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-14 03:49 +0000
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-13 21:28 -0700
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-14 09:52 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-14 12:11 -0400
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-14 14:27 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-14 20:14 +0000
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-19 12:20 +0200
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-21 09:30 -0400
Re: Where to locate software Richard Levitte <richard@levitte.org> - 2016-06-21 09:34 -0700
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-07-02 08:23 +0200
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-14 16:22 -0700
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-14 16:20 -0700
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-21 09:28 -0400
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-14 18:55 -0500
Re: Where to locate software Johnny Billquist <bqt@softjar.se> - 2016-06-15 11:18 +0200
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-15 12:17 +0000
Re: Where to locate software Johnny Billquist <bqt@softjar.se> - 2016-06-15 14:30 +0200
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-15 07:39 -0500
Re: Where to locate software Johnny Billquist <bqt@softjar.se> - 2016-06-15 15:23 +0200
Re: Where to locate software "Craig A. Berry" <craig.a.berry@gmail.com> - 2016-06-15 08:03 -0700
Re: Where to locate software Johnny Billquist <bqt@softjar.se> - 2016-06-15 19:41 +0200
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-15 19:10 -0500
Re: Where to locate software Johnny Billquist <bqt@softjar.se> - 2016-06-16 11:24 +0200
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-16 08:33 -0500
Re: Where to locate software Johnny Billquist <bqt@softjar.se> - 2016-06-16 17:09 +0200
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-16 11:12 -0500
Re: Where to locate software Richard Levitte <richard@levitte.org> - 2016-06-16 12:32 -0700
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-16 17:48 -0500
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-16 20:29 -0700
Re: Where to locate software Richard Levitte <richard@levitte.org> - 2016-06-16 23:21 -0700
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-19 05:56 +0200
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-13 13:21 -0400
Re: Where to locate software John Reagan <xyzzy1959@gmail.com> - 2016-06-12 14:46 -0700
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-12 17:53 -0700
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-12 12:57 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 18:03 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-12 12:46 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-11 22:37 -0400
Re: Where to locate software Chris Scheers <chris@applied-synergy.com> - 2016-06-10 13:28 -0500
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 11:30 -0400
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 12:48 -0400
Re: Where to locate software Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-09 18:55 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 16:00 -0400
Re: Where to locate software johnwallace4@yahoo.co.uk - 2016-06-09 14:18 -0700
Microsoft "innovation", was: Re: Where to locate software Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-10 17:47 +0000
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 22:26 -0400
Re: Where to locate software Dale Dellutri <daQQQle@panQQQix.com> - 2016-06-09 15:17 +0000
Re: Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-09 19:29 -0500
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-10 06:23 +0200
Re: Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-09 23:45 -0500
Re: Where to locate software Steven Schweda <sms.antinode@gmail.com> - 2016-06-09 21:51 -0700
Re: Where to locate software Hans Vlems <hvlems@freenet.de> - 2016-06-10 00:15 -0700
Re: Where to locate software "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-10 08:26 -0500
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-14 12:11 -0400 |
| Message-ID | <njpaav$u5e$1@dont-email.me> |
| In reply to | #58356 |
Bob Koehler wrote: > In article <njnoq5$tjj$1@dont-email.me>, "Craig A. Berry" <craigberry@nospam.mac.com> writes: >> The "D" in DVCS stands for distributed. If you have to wait for someone >> else to finish with a file before you can work on it, you're doing the >> opposite of distributed development and are defeating concurrency in >> your development process. Too much locking increases contention in human >> systems as well as software systems. > > Exactly the comment I was expecting. > > If you think locking means no concurrent development, you don't know > electronic CM systems very well. Unlocked access is only one way to > achieve concurrency. > This whole discussion about locking code seems to be unhelpful, if one considers it must be one or another. As an example, in RMS one can read and lock a record for later update, and one can read regardless and cannot update. Should not both of those concepts be in a code management system? Or, am I not understanding the problem at all?
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hoffman <seaohveh@hoffmanlabs.invalid> |
|---|---|
| Date | 2016-06-14 14:27 -0400 |
| Message-ID | <njpiab$vc4$1@dont-email.me> |
| In reply to | #58360 |
On 2016-06-14 16:11:10 +0000, David Froble said: > This whole discussion about locking code seems to be unhelpful, if one > considers it must be one or another. > > As an example, in RMS one can read and lock a record for later update, > and one can read regardless and cannot update. Should not both of > those concepts be in a code management system? > > Or, am I not understanding the problem at all? What the folks are referring to as "locking" is also commonly called "checking out" or "reserving", and "checking in" or "replacing" or "adding" or "committing" or "pushing" source code modules back into the source pool. Different packages have different sequences. The RMS record-level analog of some is a read-regardless, followed by a read-compare and either an update or a merge and update. Sequences which lock the record then force other threads to deal with the lock, or to override it and read the lock, or to include some sort of revocation and release on specified criteria; lock has aged out, the requestor being on holiday, whatever. And I'd suggest not trying to map RMS records to source control, as there's far more to this around both transactional operations, and the folks that expect to identify specific source code releases and change propagation and other details — this is akin to tracking individual records over the lifetime of the file, often with branching and merging for side-projects, testing or trial projects, and extended development efforts. Some folks centralize all code operations on one host or one cluster, and prefer to copy and resynchronize and differentiate source code modules located on any other hosts using locally-written tools when working off of the source pool host. Or — as often happens — migrating from this to a more distributed approach is non-trivial. A distributed approach using a DVCS package has either entirely private or shared or externally hosted source pools, and have a canonical core source pool (private to the organization or shared), but also have local-to-the-developer source pools, with remote access and offline access and easy updates of the local-to-the-developer pools based on the most current pool contents of the shared pool. Both centralized/VCS packages and distributed/DVCS packages can and variously do provide reservations, merges, code reviews and other features. The features and commands and sequences for these VCS and DVCS packages varies. Examples of DVCS packages include git and Mercurial as have been discussed, and others. Fossil is one of the others and tends to get rather less coverage, but is quite interesting. http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki -- Pure Personal Opinion | HoffmanLabs LLC
[toc] | [prev] | [next] | [standalone]
| From | Kerry Main <kerry.main@backtothefutureit.com> |
|---|---|
| Date | 2016-06-14 20:14 +0000 |
| Message-ID | <mailman.6.1465935333.13355.info-vax_info-vax.com@info-vax.com> |
| In reply to | #58368 |
> -----Original Message----- > From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of > Stephen Hoffman via Info-vax > Sent: 14-Jun-16 2:27 PM > To: info-vax@info-vax.com > Cc: Stephen Hoffman <seaohveh@hoffmanlabs.invalid> > Subject: Re: [New Info-vax] Where to locate software > > On 2016-06-14 16:11:10 +0000, David Froble said: > > > This whole discussion about locking code seems to be unhelpful, if one > > considers it must be one or another. > > > > As an example, in RMS one can read and lock a record for later update, > > and one can read regardless and cannot update. Should not both of > > those concepts be in a code management system? > > > > Or, am I not understanding the problem at all? > > What the folks are referring to as "locking" is also commonly called > "checking out" or "reserving", and "checking in" or "replacing" or > "adding" or "committing" or "pushing" source code modules back into > the > source pool. > > Different packages have different sequences. > > The RMS record-level analog of some is a read-regardless, followed by a > read-compare and either an update or a merge and update. Sequences > which lock the record then force other threads to deal with the lock, > or to override it and read the lock, or to include some sort of > revocation and release on specified criteria; lock has aged out, the > requestor being on holiday, whatever. And I'd suggest not trying to > map RMS records to source control, as there's far more to this around > both transactional operations, and the folks that expect to identify > specific source code releases and change propagation and other details > — this is akin to tracking individual records over the lifetime of the > file, often with branching and merging for side-projects, testing or > trial projects, and extended development efforts. > > Some folks centralize all code operations on one host or one cluster, > and prefer to copy and resynchronize and differentiate source code > modules located on any other hosts using locally-written tools when > working off of the source pool host. Or — as often happens — migrating > from this to a more distributed approach is non-trivial. > > A distributed approach using a DVCS package has either entirely private > or shared or externally hosted source pools, and have a canonical core > source pool (private to the organization or shared), but also have > local-to-the-developer source pools, with remote access and offline > access and easy updates of the local-to-the-developer pools based on > the most current pool contents of the shared pool. > > Both centralized/VCS packages and distributed/DVCS packages can and > variously do provide reservations, merges, code reviews and other > features. The features and commands and sequences for these VCS > and > DVCS packages varies. > > Examples of DVCS packages include git and Mercurial as have been > discussed, and others. Fossil is one of the others and tends to get > rather less coverage, but is quite interesting. > http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki > Although it is UNIX focused, the link posted earlier by Lawrence is pretty good at explaining VCS theory and the various options- http://www.catb.org/esr/writings/version-control/version-control.html#why_vcs As an example - Extract: comparing DVCS vs. CVCS "One is that a single repository is a single point of failure — if the repository server is down all work stops. The other is that you need to be connected live to the server to do checkins and checkouts; if you're offline, you can't work." In the OpenVMS world, you would simply configure a central dev cluster (or multi-site cluster if DR needed), so the "server" being down is much less of an issue than in the past. Additional servers are still seen as a single server to the developers and adds additional capacity for compiles etc. The justification of needing to work while being offline is getting harder to justify because of all the connectivity and WIFI options available today. Some airlines even offer Internet on flights now. Railways have been offering Internet for years. Course, you could state you need to work offline while riding in a google driverless car, but then they will likely have connectivity in the car as well. :-) Regards, Kerry Main Kerry dot main at starkgaming dot com
[toc] | [prev] | [next] | [standalone]
| From | Paul Sture <nospam@sture.ch> |
|---|---|
| Date | 2016-06-19 12:20 +0200 |
| Message-ID | <n78i3d-h3e.ln1@news.chingola.ch> |
| In reply to | #58368 |
On 2016-06-14, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote: > > Examples of DVCS packages include git and Mercurial as have been > discussed, and others. Fossil is one of the others and tends to get > rather less coverage, but is quite interesting. > http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki Interesting. Fossil versus Git: <http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki> "Git provides file versioning services only, whereas Fossil adds integrated wiki, ticketing & bug tracking, embedded documentation, and Technical notes." -- There are two hard things in computer science, and they are cache invalidation, naming, and off-by-one errors.
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.decuserve.org (Bob Koehler) |
|---|---|
| Date | 2016-06-21 09:30 -0400 |
| Message-ID | <Zly2NTzODcUs@eisner.encompasserve.org> |
| In reply to | #58596 |
In article <n78i3d-h3e.ln1@news.chingola.ch>, Paul Sture <nospam@sture.ch> writes: > > "Git provides file versioning services only, whereas Fossil adds > integrated wiki, ticketing & bug tracking, embedded documentation, and > Technical notes." Odd statement, since those features are exactly what one of our developments is using git for.
[toc] | [prev] | [next] | [standalone]
| From | Richard Levitte <richard@levitte.org> |
|---|---|
| Date | 2016-06-21 09:34 -0700 |
| Message-ID | <118df428-8a0b-4c73-8d6a-28660f13fab9@googlegroups.com> |
| In reply to | #58705 |
Den tisdag 21 juni 2016 kl. 15:32:18 UTC+2 skrev Bob Koehler: > In article <n78i3d-h3e.ln1@news.chingola.ch>, Paul Sture <nospam@sture.ch> writes: > > > > "Git provides file versioning services only, whereas Fossil adds > > integrated wiki, ticketing & bug tracking, embedded documentation, and > > Technical notes." > > Odd statement, since those features are exactly what one of our > developments is using git for. I assume that's with a bit more software on top of git, right? After all, systems like gitlab, redmine and a slew of others provide the same functionality that fossil is about... Cheers, Richard
[toc] | [prev] | [next] | [standalone]
| From | Paul Sture <nospam@sture.ch> |
|---|---|
| Date | 2016-07-02 08:23 +0200 |
| Message-ID | <f83k4d-1t4.ln1@news.chingola.ch> |
| In reply to | #58368 |
On 2016-06-14, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
> Examples of DVCS packages include git and Mercurial as have been
> discussed, and others. Fossil is one of the others and tends to get
> rather less coverage, but is quite interesting.
> http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki
I've now had a chance to try Fossil on a real life problem and find it
very comfortable to work with.
Being from the same stable as SQLite (and used for the SQLite
documentation), it's likely to be around and maintained for the
foreseeable future. :-)
--
A sure cure for sea-sickness is to sit under a tree.
-- Spike Milligan
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-14 16:22 -0700 |
| Message-ID | <dfcb99f1-3273-45b0-af9e-c47d1675f1c7@googlegroups.com> |
| In reply to | #58360 |
On Wednesday, June 15, 2016 at 4:11:12 AM UTC+12, David Froble wrote: > As an example, in RMS one can read and lock a record for later update, and one > can read regardless and cannot update. Should not both of those concepts be in > a code management system? People are not RMS-using automata. They work in many different ways. They collaborate informally. They may be doing more than one thing at a time. A VCS has to work the way people work, not how you think they should work.
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-14 16:20 -0700 |
| Message-ID | <f2bb8e70-ba0d-4fbe-b7ca-da6421b642f4@googlegroups.com> |
| In reply to | #58356 |
On Wednesday, June 15, 2016 at 1:54:08 AM UTC+12, Bob Koehler wrote: > If you think locking means no concurrent development, you don't know > electronic CM systems very well. Unlocked access is only one way to > achieve concurrency. One thing we do know, after all these years of experience, is that locking is not helpful at all.
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.decuserve.org (Bob Koehler) |
|---|---|
| Date | 2016-06-21 09:28 -0400 |
| Message-ID | <HBTBZy42tw1c@eisner.encompasserve.org> |
| In reply to | #58380 |
In article <f2bb8e70-ba0d-4fbe-b7ca-da6421b642f4@googlegroups.com>, lawrencedo99@gmail.com writes: > On Wednesday, June 15, 2016 at 1:54:08 AM UTC+12, Bob Koehler wrote: > >> If you think locking means no concurrent development, you don't know >> electronic CM systems very well. Unlocked access is only one way to >> achieve concurrency. > > One thing we do know, after all these years of experience, is that locking is not helpful at all. In that case, you have years of experience doing it wrong.
[toc] | [prev] | [next] | [standalone]
| From | "Craig A. Berry" <craigberry@nospam.mac.com> |
|---|---|
| Date | 2016-06-14 18:55 -0500 |
| Message-ID | <njq5hd$6dr$1@dont-email.me> |
| In reply to | #58356 |
On 6/14/16 8:52 AM, Bob Koehler wrote: > In article <njnoq5$tjj$1@dont-email.me>, "Craig A. Berry" <craigberry@nospam.mac.com> writes: >> >> The "D" in DVCS stands for distributed. If you have to wait for someone >> else to finish with a file before you can work on it, you're doing the >> opposite of distributed development and are defeating concurrency in >> your development process. Too much locking increases contention in human >> systems as well as software systems. > > Exactly the comment I was expecting. > > If you think locking means no concurrent development, you don't know > electronic CM systems very well. Unlocked access is only one way to > achieve concurrency. I was responding to Kerry, whose goal is "to prevent code from being updated" when one developer has something checked out. The fact that some centralized VCS's can allow a degree of concurrency via branching is beside the point in that scenario. And you'll very likely still find locking per branch and have to choose between branching by feature and branching by developer. With a DVCS you don't have to choose.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-15 11:18 +0200 |
| Message-ID | <njr6hl$ins$1@Iltempo.Update.UU.SE> |
| In reply to | #58382 |
On 2016-06-15 01:55, Craig A. Berry wrote: > On 6/14/16 8:52 AM, Bob Koehler wrote: >> In article <njnoq5$tjj$1@dont-email.me>, "Craig A. Berry" >> <craigberry@nospam.mac.com> writes: >>> >>> The "D" in DVCS stands for distributed. If you have to wait for someone >>> else to finish with a file before you can work on it, you're doing the >>> opposite of distributed development and are defeating concurrency in >>> your development process. Too much locking increases contention in human >>> systems as well as software systems. >> >> Exactly the comment I was expecting. >> >> If you think locking means no concurrent development, you don't know >> electronic CM systems very well. Unlocked access is only one way to >> achieve concurrency. > > I was responding to Kerry, whose goal is "to prevent code from being > updated" when one developer has something checked out. The fact that > some centralized VCS's can allow a degree of concurrency via branching > is beside the point in that scenario. And you'll very likely still find > locking per branch and have to choose between branching by feature and > branching by developer. With a DVCS you don't have to choose. I've been trying to keep out of this thread, but could people just clarify one thing for me. What is CVS and SVN classified as here? Are they distributed version control systems, or centralized? Because the normal flow of work is never that you lock files when working on them in these systems, but I did get the impressions that people classified them as centralized. Which then confuses me, as people somehow put an equal sign between centralized and locking. And if CVS and SVN are defined as distributed, then what is the argument between them and GIT about? Johnny
[toc] | [prev] | [next] | [standalone]
| From | Kerry Main <kerry.main@backtothefutureit.com> |
|---|---|
| Date | 2016-06-15 12:17 +0000 |
| Message-ID | <mailman.306.1465993099.14919.info-vax_info-vax.com@info-vax.com> |
| In reply to | #58394 |
> -----Original Message----- > From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of > Johnny Billquist via Info-vax > Sent: 15-Jun-16 5:19 AM > To: info-vax@info-vax.com > Cc: Johnny Billquist <bqt@softjar.se> > Subject: Re: [New Info-vax] Where to locate software [snip..] > I've been trying to keep out of this thread, but could people just > clarify one thing for me. What is CVS and SVN classified as here? Are > they distributed version control systems, or centralized? > > Because the normal flow of work is never that you lock files when > working on them in these systems, but I did get the impressions that > people classified them as centralized. Which then confuses me, as > people > somehow put an equal sign between centralized and locking. > > And if CVS and SVN are defined as distributed, then what is the > argument > between them and GIT about? > > Johnny >From earlier post by Lawrence - article has nice theory and summary (bit dated, but still pretty good) http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki Regards, Kerry Main Kerry dot main at starkgaming dot com
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-15 14:30 +0200 |
| Message-ID | <njrhps$b6t$1@Iltempo.Update.UU.SE> |
| In reply to | #58410 |
On 2016-06-15 14:17, Kerry Main wrote: >> -----Original Message----- >> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of >> Johnny Billquist via Info-vax >> Sent: 15-Jun-16 5:19 AM >> To: info-vax@info-vax.com >> Cc: Johnny Billquist <bqt@softjar.se> >> Subject: Re: [New Info-vax] Where to locate software > > [snip..] > >> I've been trying to keep out of this thread, but could people just >> clarify one thing for me. What is CVS and SVN classified as here? Are >> they distributed version control systems, or centralized? >> >> Because the normal flow of work is never that you lock files when >> working on them in these systems, but I did get the impressions that >> people classified them as centralized. Which then confuses me, as >> people >> somehow put an equal sign between centralized and locking. >> >> And if CVS and SVN are defined as distributed, then what is the >> argument >> between them and GIT about? >> >> Johnny > >>From earlier post by Lawrence - article has nice theory and summary > (bit dated, but still pretty good) > > http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki Thanks. Not what I asked, but still interesting to check out. Johnny
[toc] | [prev] | [next] | [standalone]
| From | "Craig A. Berry" <craigberry@nospam.mac.com> |
|---|---|
| Date | 2016-06-15 07:39 -0500 |
| Message-ID | <njriah$634$1@dont-email.me> |
| In reply to | #58394 |
On 6/15/16 4:18 AM, Johnny Billquist wrote: > I've been trying to keep out of this thread, but could people just > clarify one thing for me. What is CVS and SVN classified as here? Are > they distributed version control systems, or centralized? Centralized. > Because the normal flow of work is never that you lock files when > working on them in these systems, but I did get the impressions that > people classified them as centralized. If "working on them" does not include doing any commits, then I suppose that's true. But one of the things you get used to with a DVCS and miss when you don't have it is the ability to commit willy nilly, go wild with experiments, and then revise those commits, perhaps "squash" a string of smaller commits into fewer more coherent ones, all before pushing them to a repository where others can see them. > Which then confuses me, as people > somehow put an equal sign between centralized and locking. There is no equals sign. Some of them do have checkouts that include preventing others from making changes to whatever is checked out. This is a traditional way of doing things that's ok for a small team but doesn't scale. > And if CVS and SVN are defined as distributed, then what is the argument > between them and GIT about? > > Johnny >
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-15 15:23 +0200 |
| Message-ID | <njrksq$hfr$1@Iltempo.Update.UU.SE> |
| In reply to | #58415 |
On 2016-06-15 14:39, Craig A. Berry wrote: > On 6/15/16 4:18 AM, Johnny Billquist wrote: > >> I've been trying to keep out of this thread, but could people just >> clarify one thing for me. What is CVS and SVN classified as here? Are >> they distributed version control systems, or centralized? > > Centralized. Ok. >> Because the normal flow of work is never that you lock files when >> working on them in these systems, but I did get the impressions that >> people classified them as centralized. > > If "working on them" does not include doing any commits, then I suppose > that's true. But one of the things you get used to with a DVCS and miss > when you don't have it is the ability to commit willy nilly, go wild > with experiments, and then revise those commits, perhaps "squash" a > string of smaller commits into fewer more coherent ones, all before > pushing them to a repository where others can see them. Well, I definitely can, and do work in this pattern with CVS and SVN as well. So I can't say that this is in any way something defining of a distributed version control system then. (The way you do this is that you create a branch where you do all your experimentation, and then you merge back to the source when you want others to see it. And yes, you can have several people working on your experimental branch in parallel as well. And they can all check in and out things concurrently. This is what branches exist for.) >> Which then confuses me, as people >> somehow put an equal sign between centralized and locking. > > There is no equals sign. Some of them do have checkouts that include > preventing others from making changes to whatever is checked out. This > is a traditional way of doing things that's ok for a small team but > doesn't scale. Thanks. Because I was having problems with what I perceived as an equal sign in there. Removed from my brain now. Johnny
[toc] | [prev] | [next] | [standalone]
| From | "Craig A. Berry" <craig.a.berry@gmail.com> |
|---|---|
| Date | 2016-06-15 08:03 -0700 |
| Message-ID | <2af1c4fb-7570-4c14-997f-d1e157a33c8a@googlegroups.com> |
| In reply to | #58417 |
On Wednesday, June 15, 2016 at 8:23:40 AM UTC-5, Johnny Billquist wrote: > On 2016-06-15 14:39, Craig A. Berry wrote: > > On 6/15/16 4:18 AM, Johnny Billquist wrote: > > > >> I've been trying to keep out of this thread, but could people just > >> clarify one thing for me. What is CVS and SVN classified as here? Are > >> they distributed version control systems, or centralized? > > > > Centralized. > > Ok. > > >> Because the normal flow of work is never that you lock files when > >> working on them in these systems, but I did get the impressions that > >> people classified them as centralized. > > > > If "working on them" does not include doing any commits, then I suppose > > that's true. But one of the things you get used to with a DVCS and miss > > when you don't have it is the ability to commit willy nilly, go wild > > with experiments, and then revise those commits, perhaps "squash" a > > string of smaller commits into fewer more coherent ones, all before > > pushing them to a repository where others can see them. > > Well, I definitely can, and do work in this pattern with CVS and SVN as > well. So I can't say that this is in any way something defining of a > distributed version control system then. > > (The way you do this is that you create a branch where you do all your > experimentation, and then you merge back to the source when you want > others to see it. And yes, you can have several people working on your > experimental branch in parallel as well. And they can all check in and > out things concurrently. This is what branches exist for.) It's not the same thing. The branches (even nominally "private" ones) exist on the server in a centralized VCS. Plus there is no distinction between commit and push; if you create a changeset, you are creating it on the server. (Unless you have a completely private repository, I guess.) I'm not saying DVCS's are a panacea but I do think folks ought to try them if they haven't yet. The learning curve can be steep but you can do a lot even with just a small subset of the available features. I was dragged kicking and screaming into using git when Perl switched from Perforce to git a few years ago. Now I can't imagine going back to a centralized VCS in a situation where I can choose.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-15 19:41 +0200 |
| Message-ID | <njs40a$ka1$1@Iltempo.Update.UU.SE> |
| In reply to | #58422 |
On 2016-06-15 17:03, Craig A. Berry wrote: > On Wednesday, June 15, 2016 at 8:23:40 AM UTC-5, Johnny Billquist wrote: >> On 2016-06-15 14:39, Craig A. Berry wrote: >>> On 6/15/16 4:18 AM, Johnny Billquist wrote: >>> >>>> I've been trying to keep out of this thread, but could people just >>>> clarify one thing for me. What is CVS and SVN classified as here? Are >>>> they distributed version control systems, or centralized? >>> >>> Centralized. >> >> Ok. >> >>>> Because the normal flow of work is never that you lock files when >>>> working on them in these systems, but I did get the impressions that >>>> people classified them as centralized. >>> >>> If "working on them" does not include doing any commits, then I suppose >>> that's true. But one of the things you get used to with a DVCS and miss >>> when you don't have it is the ability to commit willy nilly, go wild >>> with experiments, and then revise those commits, perhaps "squash" a >>> string of smaller commits into fewer more coherent ones, all before >>> pushing them to a repository where others can see them. >> >> Well, I definitely can, and do work in this pattern with CVS and SVN as >> well. So I can't say that this is in any way something defining of a >> distributed version control system then. >> >> (The way you do this is that you create a branch where you do all your >> experimentation, and then you merge back to the source when you want >> others to see it. And yes, you can have several people working on your >> experimental branch in parallel as well. And they can all check in and >> out things concurrently. This is what branches exist for.) > > It's not the same thing. The branches (even nominally "private" ones) exist on the server in a centralized VCS. Plus there is no distinction between commit and push; if you create a changeset, you are creating it on the server. (Unless you have a completely private repository, I guess.) But now you are talking about technical implementation details. The usage pattern is the same. It's not that git enables me to do something I couldn't already do, it just have different names, and different technical solutions to how it might be done. But I will not be doing my work in any different way. > I'm not saying DVCS's are a panacea but I do think folks ought to try them if they haven't yet. The learning curve can be steep but you can do a lot even with just a small subset of the available features. I was dragged kicking and screaming into using git when Perl switched from Perforce to git a few years ago. Now I can't imagine going back to a centralized VCS in a situation where I can choose. I've used CVS, SVN, GIT, and a load of other version control systems over the years. I can't say that I've become friends with GIT yet. In fact, I've manged to mess it up enough a few times that experts on GIT just told me to wipe everything local and start over. I guess that tells something of my inability so far to become friends with GIT. But that is beside the point. There are some things easier or "better" (for some definition of better) done in some systems than others. But it's just shades. Many version control systems allow you to do the work you need, in similar ways, no matter if they call themselves distributed or centralized. I think it is a mistake to claim that distributed vs. centralized in itself is any big point either way. It's more a question of what operations do you want to do, and can you do them without bending over backwards. The one big problem in CVS and SVN is really doing multiple merges between branches, where you need to keep track of where you did the last marge, to just get the correct deltas. As far as I understand, GIT handles this much better. People whole rave about SVN over CVS usually go on about how cheap branches are. Personally I find that to be a pretty uninteresting detail, which don't help me at all. So in the end, SVN is for me pretty much identical to CVS. And there are some things I find much easier to do with CVS, so I might pick CVS over SVN. But of course, people have different preferences when it comes to that. But GIT people seems to think there is some built-in supremacy in some things in GIT which I don't get. Anyway, I was just getting curious about the whole debate on distributed vs. centralized, and the description of them in this thread, which seemed to attribute limitations to "centralized" version control systems that I just felt were incorrect, but I wanted to make sure I understood how the terms were used before I decided whether I was just going to ignore the thread as being nonsense. Johnny
[toc] | [prev] | [next] | [standalone]
| From | "Craig A. Berry" <craigberry@nospam.mac.com> |
|---|---|
| Date | 2016-06-15 19:10 -0500 |
| Message-ID | <njsqpt$t9r$1@dont-email.me> |
| In reply to | #58426 |
On 6/15/16 12:41 PM, Johnny Billquist wrote: > On 2016-06-15 17:03, Craig A. Berry wrote: >> On Wednesday, June 15, 2016 at 8:23:40 AM UTC-5, Johnny Billquist wrote: >>> On 2016-06-15 14:39, Craig A. Berry wrote: >>>> On 6/15/16 4:18 AM, Johnny Billquist wrote: >>> (The way you do this is that you create a branch where you do all your >>> experimentation, and then you merge back to the source when you want >>> others to see it. And yes, you can have several people working on your >>> experimental branch in parallel as well. And they can all check in and >>> out things concurrently. This is what branches exist for.) >> >> It's not the same thing. The branches (even nominally "private" ones) >> exist on the server in a centralized VCS. Plus there is no >> distinction between commit and push; if you create a changeset, you >> are creating it on the server. (Unless you have a completely private >> repository, I guess.) > > But now you are talking about technical implementation details. The > usage pattern is the same. It's not that git enables me to do something > I couldn't already do, it just have different names, and different > technical solutions to how it might be done. If needing to communicate with the server is the same thing as not needing to communicate with the server, and being unable to commit without publishing is the same thing as being able to commit without publishing, and being unable to create a changeset without contending with other users' changes is the same thing as being able to do so, then yeah, it's all the same. In other words, if you don't understand or refuse to use the features of a DVCS, then it's the same as a centralized VCS. > But I will not be doing my work in any different way. That I believe.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-16 11:24 +0200 |
| Message-ID | <njtr7l$s0b$1@Iltempo.Update.UU.SE> |
| In reply to | #58433 |
On 2016-06-16 02:10, Craig A. Berry wrote: > On 6/15/16 12:41 PM, Johnny Billquist wrote: >> On 2016-06-15 17:03, Craig A. Berry wrote: >>> On Wednesday, June 15, 2016 at 8:23:40 AM UTC-5, Johnny Billquist wrote: >>>> On 2016-06-15 14:39, Craig A. Berry wrote: >>>>> On 6/15/16 4:18 AM, Johnny Billquist wrote: > >>>> (The way you do this is that you create a branch where you do all your >>>> experimentation, and then you merge back to the source when you want >>>> others to see it. And yes, you can have several people working on your >>>> experimental branch in parallel as well. And they can all check in and >>>> out things concurrently. This is what branches exist for.) >>> >>> It's not the same thing. The branches (even nominally "private" ones) >>> exist on the server in a centralized VCS. Plus there is no >>> distinction between commit and push; if you create a changeset, you >>> are creating it on the server. (Unless you have a completely private >>> repository, I guess.) >> >> But now you are talking about technical implementation details. The >> usage pattern is the same. It's not that git enables me to do something >> I couldn't already do, it just have different names, and different >> technical solutions to how it might be done. > > If needing to communicate with the server is the same thing as not > needing to communicate with the server, and being unable to commit > without publishing is the same thing as being able to commit without > publishing, and being unable to create a changeset without contending > with other users' changes is the same thing as being able to do so, then > yeah, it's all the same. In other words, if you don't understand or > refuse to use the features of a DVCS, then it's the same as a > centralized VCS. You have a good point about being able to work offline. That is definitely a difference. And that is more what I could argue is a difference between a centralized and distributed system, and an advantage with a distributed system. The distinction between committing and publishing on the other hand is not really anything that impress me. It's more a crutch for people who are afraid to commit. But the talk about creating a changeset without contending with other users users changes more sounds like you have not understood branches. Or I could ask it this way: what contention??? >> But I will not be doing my work in any different way. > > That I believe. :-) Johnny
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.os.vms
csiph-web