Re: cvs better than git?
At Sun, 21 Jun 2020 17:45:44 +0200, Johnny Billquist wrote: Subject: Re: cvs better than git? > > Something done on your local repository is not truly committed to > start with. And it should be run through unit tests and so on, on the > central repository, before being committed to the central repository. Actually that's not true, for any DVCS. The hash that identifies a commit remains the same no matter where or when it is pushed or pulled, and of course if the hash doesn't change then neither does the code. Once you have a commit-ID you know _exactly_ what you have in every file and in every directory of the working tree, no matter where you take it. So with a DVCS of any kind you have to learn to distinguish between various sources of various kinds of authority. In most any DVCS, I think, and certainly in Git, it is easy to set up a process that strictly implements a review process such that what ends up on an authoritative branch in an authoritative repository (e.g. "trunk" in the main project's primary repository on a central Git server) has been fully tested and fully reviewed by as many people as required, yet it should have the same commit-ID as it did when it was first committed to some developer's repository on whatever machine they were on when they completed it (there may be another node or two on the DAG to account for merges, but the original node represents the code exactly as it was on that final commit). -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgp3Oz8QFxccu.pgp Description: OpenPGP Digital Signature
Re: cvs better than git?
On Sun, Jun 21, 2020 at 06:48:54PM +0100, Sad Clouds wrote: > On Sun, 21 Jun 2020 18:26:48 +0200 > Johnny Billquist wrote: > > > I hear what you say, but it's still a fact that even good people make > > errors all the time. So it's not really that much about "trust" as > > about in the end getting the damn thing right. Prestige have no place > > there. If you think you write perfect code, and if you feel anyone > > looking over your should is an insult, then I think you should think > > again. :-) > > It's not about being insulted, but more about getting the work done > without being blocked needlessly. As a practical example: > > If I have a problem with my car and I think I can fix it better than > anyone else, I roll up my sleeves and do it. > > Otherwise, I take it to a garage and let them do it for me. Whether they > do a good or a bad job, I don't stand there reviewing their work and > giving them my critique on every nut and bolt they replace. If they do > a bad job, I just don't come back there again. Perhaps; but if you do major work on a car, then you need to take it to an expert to get signed off before you're legally allowed to drive on public roads - at least, that's true here in NSW, Australia, and I'd imagine fairly common elsewhere. -- Paul Ripke "Great minds discuss ideas, average minds discuss events, small minds discuss people." -- Disputed: Often attributed to Eleanor Roosevelt. 1948.
Re: cvs better than git?
On Sun, 21 Jun 2020 17:36:23 +0200 Andreas Krey wrote: > > Even when you have unit tests (which you should), there are still plenty > > of errors not caught by that. However, automatically running unit tests > > on all code to be committed, *before* it is committed, is also very > > valuable. > > In git, commits are not final As a long time SVN user trying to stay out of this discussion... I give up. This partial sentence broke my willpower. ...if it's not final, why is it called a "commit"? -- Aaron B.
Re: Checking out src with Mercurial
On Sun, Jun 21, 2020 at 12:36 PM Mayuresh wrote: > > On Sun, Jun 21, 2020 at 11:56:20AM -0400, matthew sporleder wrote: > > > > > > the way git works (tracking whole trees at a time, never single files), > > > that ends up being very painful, because it's an "all or nothing" > > > approach. > > > > > > So I'm hoping that if you guys are seriously considering git, you'd also > > > split up the KDE repository so that it's not one single huge one, but with > > > multiple smaller repositories > > > > > Just so that above point is not missed. Above point is not out of date. It > applies to both hg and git - splitting a large repository when using > distributed ones. > > > This is out of date. FreeBSD is moving to git. > > Interesting... I could not find that in official documents as yet. Yes, > there have been git mirrors. The last two status reports: "The Core-initiated Git Transition Working Group continued to meet over the last quarter of 2019. Their report is still forthcoming. " https://www.freebsd.org/news/status/report-2020-01-2020-03.html
Re: cvs better than git?
On Sun, 21 Jun 2020 18:26:48 +0200 Johnny Billquist wrote: > I hear what you say, but it's still a fact that even good people make > errors all the time. So it's not really that much about "trust" as > about in the end getting the damn thing right. Prestige have no place > there. If you think you write perfect code, and if you feel anyone > looking over your should is an insult, then I think you should think > again. :-) It's not about being insulted, but more about getting the work done without being blocked needlessly. As a practical example: If I have a problem with my car and I think I can fix it better than anyone else, I roll up my sleeves and do it. Otherwise, I take it to a garage and let them do it for me. Whether they do a good or a bad job, I don't stand there reviewing their work and giving them my critique on every nut and bolt they replace. If they do a bad job, I just don't come back there again.
Re: cvs better than git?
On 2020-06-21 18:49, Andreas Krey wrote: On Sun, 21 Jun 2020 18:34:30 +, Johnny Billquist wrote: ... That is what literally the word "commit" means. Until that point, you are not committed. Please excuse me for not getting that, with 'committing', you don't mean creating git commits in the context of talking about git. I mean, that you don't 'commit' things that aren't reviewed, is blindingly obvious. Whether you do reviews before doing a 'git commit' is not. Ok. One final time: In the end, the code lives somewhere central, from where everyone gets the code. Committing code to this repository is the only thing that matters, and that is what I am talking about the whole time. What the exact terminology is used in a specific tool is irrelevant. You need to understand the concept, and talk about that irrespective of what it is called in your tool. Since different tools have different terminology anyway, it is not useful, ever, to to talk about general concepts using a specific tools terminology. If you can't see that, it's not my problem. This whole thread is not purely about git, but also how to deal with different problems and issues, partly in relationship with git, but not based on git. And I have absolutely no interest in trying to convince you that git sucks. You didn't even start with that. You just continued to claim that it doesn't work in some unspecified way. Well. You haven't presented any proof that git even works in the first place. So I think I can rest easy on that one. ... the true believers. I don't care about them. They're not helpful. You certainly come across as one of them. And you're about equally as helpful. Now I'm truly done. Please remove me as a recipient of any more mails on this thread. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: cvs better than git?
On Sun, 21 Jun 2020 18:34:30 +, Johnny Billquist wrote: ... > That is what literally the word "commit" means. Until that point, you > are not committed. Please excuse me for not getting that, with 'committing', you don't mean creating git commits in the context of talking about git. I mean, that you don't 'commit' things that aren't reviewed, is blindingly obvious. Whether you do reviews before doing a 'git commit' is not. > And I have absolutely no interest in trying to convince you that git sucks. You didn't even start with that. You just continued to claim that it doesn't work in some unspecified way. ... > ... the true believers. I don't care about them. They're not helpful. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: netbsd 9 upgrade experience
Hi All, Thanks Greg and Martin for the hints! I had to fix them manually but managed to get it done so postinstall does not complain when I let them checked. Today when I started up the system I got in dmesg this stuff but I haven't seen that after reboot: [ 1686,631400] kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_sprite.c:132)intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A: -35 I don't know if it helps (if anyone has time for it at all) besides the xdm.log and Xorg.0.log sent yesterday. Best regards, r0ller Eredeti levél Feladó: Martin Husemann < mar...@duskware.de (Link -> mailto:mar...@duskware.de) > Dátum: 2020 június 21 07:53:58 Tárgy: Re: netbsd 9 upgrade experience Címzett: Greg Troxel < g...@lexort.com (Link -> mailto:g...@lexort.com) > On Sat, Jun 20, 2020 at 08:13:42PM -0400, Greg Troxel wrote: > This is the easy one. postinstall expects sources. You can use the -s > option. I unpack etc.tgz and xetc.tgz to /usr/netbsd-etc and pass that. > Amazingly, this is even in the manual, but it doesn't really say that > you need a plan for -s. Back in the days when sysinst started running postinstall after updates there were no cases when postinstall needed manual intervention. We need to deal with this in sysinst somehow(tm). The black xdm fields will go away once postinstall fixed "x11" properly (it is caused by missing resource entries in the xdm config files). Martin
Re: cvs better than git?
On 2020-06-21 18:17, Andreas Krey wrote: On Sun, 21 Jun 2020 17:59:59 +, Johnny Billquist wrote: ... You're a bit hung up on the word 'commit', and the finality of commits in some VCSes, it seems. So are obviously everyone using git in combination with gerrit... What? The gerrit model is exactly that: Make commits to be reviewed, rewrite commits according to review feedback until everyone is satisfied; then merge in those commits. So then you didn't understand a thing I wrote then, if you think I used the words with some different meaning. What you do on your local repository is totally uninteresting. What happens where anyone else can see it is what is relevant. If you call the entire process of accepting (after finished reviewe) the final commit set, and integrating and publishing them 'committing' you'll find yourself in some trouble discussing with other people. That is what literally the word "commit" means. Until that point, you are not committed. This discussion is meaningless. You simple cannot accept that your favorite tool have warts, or that others do not think it's the best thing since sliced bread. And I have absolutely no interest in trying to convince you that git sucks. If it tickles you in all the right places, then good for you. I still hate it, and you will not convince me otherwise. I've used it enough to have an opinion of my own instead of just trusting the true believers. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Checking out src with Mercurial
On Sun, Jun 21, 2020 at 11:56:20AM -0400, matthew sporleder wrote: > > > > the way git works (tracking whole trees at a time, never single files), > > that ends up being very painful, because it's an "all or nothing" > > approach. > > > > So I'm hoping that if you guys are seriously considering git, you'd also > > split up the KDE repository so that it's not one single huge one, but with > > multiple smaller repositories > > Just so that above point is not missed. Above point is not out of date. It applies to both hg and git - splitting a large repository when using distributed ones. > This is out of date. FreeBSD is moving to git. Interesting... I could not find that in official documents as yet. Yes, there have been git mirrors.
Re: cvs better than git?
On 2020-06-21 18:17, Sad Clouds wrote: On Sun, 21 Jun 2020 17:15:44 +0200 Johnny Billquist wrote: Not talking about a specific tool, but the process then. There are multiple advantages by having code reviewed. First of all, noone is perfect. People make mistakes all the time, and having two people look at it already reduce silly errors significantly. I'm not against code reviews, and as I've mentioned, you can easily do that on the command line against a private branch, before it is merged with the main branch. Personally, I'm not that keen on the GUI process with Git, Gerrit, etc. Too much red tape and clicking on buttons. When I work with people, I want to trust them to do their job right, and don't want to monitor every line of code they write, unless of cause they ask for it. On the other side of the spectrum, sometimes you get complete control freaks, that block you all the time due to minor stylistic differences. I hear what you say, but it's still a fact that even good people make errors all the time. So it's not really that much about "trust" as about in the end getting the damn thing right. Prestige have no place there. If you think you write perfect code, and if you feel anyone looking over your should is an insult, then I think you should think again. :-) Code style is another question of process. For few people, and small systems, it's usually not a problem when it's the wild west. The more people, the larger the project, and the longer the code lives, the more does such things start to matter. And having a style guide is usually an issue for new members for the first month or two, after that there is usually very little comments about style. People adopt pretty quick. So, no, I would say it does not block you all the time, unless you insist on not following style guides. Style guides are not about right or wrong in an absolute sense, most of the time, but about having consistency. As such, I really dislike some rules of the style guides we have at work, but I definitely see the benefit when hitting some old code, when I can easily see the relevant bits without trying to penetrate whatever odd style this person used when writing the code. And that makes the code more maintainable in the long run. So I'll happily live with the stupid style guide, for that win. No two people agree on styles anyhow, but most people do agree that it's good if code look somewhat similar independent of who wrote it, especially when it comes to maintaining old code. And honestly, maintaining old code is about the most painful thing there is, many times... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: cvs better than git?
On Sun, 21 Jun 2020 17:15:44 +0200 Johnny Billquist wrote: > Not talking about a specific tool, but the process then. > > There are multiple advantages by having code reviewed. > First of all, noone is perfect. People make mistakes all the time, > and having two people look at it already reduce silly errors > significantly. I'm not against code reviews, and as I've mentioned, you can easily do that on the command line against a private branch, before it is merged with the main branch. Personally, I'm not that keen on the GUI process with Git, Gerrit, etc. Too much red tape and clicking on buttons. When I work with people, I want to trust them to do their job right, and don't want to monitor every line of code they write, unless of cause they ask for it. On the other side of the spectrum, sometimes you get complete control freaks, that block you all the time due to minor stylistic differences.
Re: cvs better than git?
On Sun, 21 Jun 2020 17:59:59 +, Johnny Billquist wrote: ... > >You're a bit hung up on the word 'commit', and the finality of commits > >in some VCSes, it seems. > > So are obviously everyone using git in combination with gerrit... What? The gerrit model is exactly that: Make commits to be reviewed, rewrite commits according to review feedback until everyone is satisfied; then merge in those commits. If you call the entire process of accepting (after finished reviewe) the final commit set, and integrating and publishing them 'committing' you'll find yourself in some trouble discussing with other people. > You could also argue that the whole point of a VCS is that once it's in > there, it's immutable, available to everyone, The point of a VCS is to record history - the history you (collectively) decide to be recorded. See the discussion about 'svn obliterate'; see discussions on how to remove accidentally committed secrets from git repos. git takes the stance that, since you can just fake the entire history (as you can, if not with, then for svn), it also lets you modify history more granularly, and gives you tools to keep parts of the history fixed - those parts that you decide should be fixed and permanent. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: cvs better than git?
On 2020-06-21 18:02, Andreas Krey wrote: On Sun, 21 Jun 2020 17:45:44 +, Johnny Billquist wrote: ... Something done on your local repository is not truly committed to start with. And it should be run through unit tests and so on, on the central repository, before being committed to the central repository. When you try to understand git's operations with your definition of some words, you will obviously run into problems. If you really think that is the problem, then we are further apart than I thought possible... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: cvs better than git?
On Sun, 21 Jun 2020 17:45:44 +, Johnny Billquist wrote: ... > Something done on your local repository is not truly committed to start > with. And it should be run through unit tests and so on, on the central > repository, before being committed to the central repository. When you try to understand git's operations with your definition of some words, you will obviously run into problems. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: cvs better than git?
On 2020-06-21 17:55, Andreas Krey wrote: On Sun, 21 Jun 2020 17:26:05 +, Johnny Billquist wrote: ... What? I can't believe you are ignorant enough to not know that each file in cvs have a version number for each commit on it. ETOOLONGAGO; this is starting to slip my mind. Yes, files have revision numbers. But they are nearly useless, and... Or refer to a revision at a certain point in time. ...referring to a specific time is the closest you can do. There is no way to refer to the state of the entire tree at the point a given file was committed in a given revision. ... See.. That is, in my book (and not only mine) a serious broken pattern. You do not commit before reviewing. To review, you need a full description of the changes: Diffs, added files, removed files, renamed files. And the intended commit message. The data structure that can already represent this is, well, a commit. This goes doubly when you don't want to commit an entire feature in a single commit - for the review you then need to further specify which changes shall go into which commit. Thus the easiest way to give to a review what you want to commit is to actually commit it and let the reviewers inspect (and the CI test) that. But ok, if that is how you work, then I guess there is not much I can learn from you in that area. Oh well. You're a bit hung up on the word 'commit', and the finality of commits in some VCSes, it seems. So are obviously everyone using git in combination with gerrit... You could also argue that the whole point of a VCS is that once it's in there, it's immutable, available to everyone, can be rolled forward and backward, have history and metadata, and so on... Otherwise you can just as well just edit your files in your directory, and that's your VCS. And anyone else you work with can get a copy through mail of the current state, or if you are fancy, they can copy directly from you directory... Instant snapshot... Who knows if it works or not. But it's always the bleeding edge... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Checking out src with Mercurial
On Sun, Jun 21, 2020 at 11:33 AM Mayuresh wrote: > > On Sat, Jun 20, 2020 at 11:35:53AM +0530, Mayuresh wrote: > > On Fri, Jun 19, 2020 at 10:01:35PM -0700, Greg A. Woods wrote: > > > (c) modern change tracking tools try to track changes to whole sets of > > > files at once, so if you have lots of files, and lots of history, > > > this combinatorial problem can sometimes bite at a bad time for the > > > user of a tool trying to manage it all. > > > > In one of the talks by Linus on git I heard him recommending breaking very > > large repositories into some smaller units to get better performance. > > > > Would it be something feasible in NetBSD? A single user requires > > approximately what % of code from what he or she checks out to be actually > > compiled and can there be 1 core and several optional repositories that > > would increase this percentage. > > Just quoting the correct reference[1]: > > > the way git works (tracking whole trees at a time, never single files), > that ends up being very painful, because it's an "all or nothing" > approach. > > So I'm hoping that if you guys are seriously considering git, you'd also > split up the KDE repository so that it's not one single huge one, but with > multiple smaller repositories > > > I think, before we adopt a centralized repository (whether hg or git) this > needs to be thought through. > > FreeBSD has been there done that when adopting SVN[2],[3] > > [1] https://lwn.net/Articles/246381/ > [2] https://wiki.freebsd.org/VCSWhy > [3] https://wiki.freebsd.org/GitDrawbacks This is out of date. FreeBSD is moving to git.
Re: cvs better than git?
On Sun, 21 Jun 2020 17:26:05 +, Johnny Billquist wrote: ... > What? I can't believe you are ignorant enough to not know that each file > in cvs have a version number for each commit on it. ETOOLONGAGO; this is starting to slip my mind. Yes, files have revision numbers. But they are nearly useless, and... > Or refer to a revision at a certain point in time. ...referring to a specific time is the closest you can do. There is no way to refer to the state of the entire tree at the point a given file was committed in a given revision. ... > See.. That is, in my book (and not only mine) a serious broken pattern. > You do not commit before reviewing. To review, you need a full description of the changes: Diffs, added files, removed files, renamed files. And the intended commit message. The data structure that can already represent this is, well, a commit. This goes doubly when you don't want to commit an entire feature in a single commit - for the review you then need to further specify which changes shall go into which commit. Thus the easiest way to give to a review what you want to commit is to actually commit it and let the reviewers inspect (and the CI test) that. > But ok, if that is how you work, then I guess there is not much I can > learn from you in that area. Oh well. You're a bit hung up on the word 'commit', and the finality of commits in some VCSes, it seems. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: cvs better than git?
On 2020-06-21 17:36, Andreas Krey wrote: On Sun, 21 Jun 2020 17:15:44 +, Johnny Billquist wrote: ... Even when you have unit tests (which you should), there are still plenty of errors not caught by that. However, automatically running unit tests on all code to be committed, *before* it is committed, is also very valuable. In git, commits are not final, and you can undo or 'modify' them.[1] Therefore there is no reason to require running tests before committing, but it rather makes sense to run tests on the *committed* state. For one, this way you see if you actually committed everything that is needed, and you still can replace the commit by a modified one if tests failed. E.g. on our primary product the developers can take the current commit in their workspace (repo), and run the CI tests on them on a server. The command that triggers this takes the current local commit, pushes it to a test repo, and a host in the test server farm picks that up. You can do that before even pushing to your branch in the central repo, i.e. before anybody seeing your commit. - Andreas [1] Still, on your central repo and branches you will disable removal of commits for the obvious reasons. Something done on your local repository is not truly committed to start with. And it should be run through unit tests and so on, on the central repository, before being committed to the central repository. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: cvs better than git?
On Sun, 21 Jun 2020 17:15:44 +, Johnny Billquist wrote: ... > Even when you have unit tests (which you should), there are still plenty > of errors not caught by that. However, automatically running unit tests > on all code to be committed, *before* it is committed, is also very > valuable. In git, commits are not final, and you can undo or 'modify' them.[1] Therefore there is no reason to require running tests before committing, but it rather makes sense to run tests on the *committed* state. For one, this way you see if you actually committed everything that is needed, and you still can replace the commit by a modified one if tests failed. E.g. on our primary product the developers can take the current commit in their workspace (repo), and run the CI tests on them on a server. The command that triggers this takes the current local commit, pushes it to a test repo, and a host in the test server farm picks that up. You can do that before even pushing to your branch in the central repo, i.e. before anybody seeing your commit. - Andreas [1] Still, on your central repo and branches you will disable removal of commits for the obvious reasons. -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Checking out src with Mercurial
On Sat, Jun 20, 2020 at 11:35:53AM +0530, Mayuresh wrote: > On Fri, Jun 19, 2020 at 10:01:35PM -0700, Greg A. Woods wrote: > > (c) modern change tracking tools try to track changes to whole sets of > > files at once, so if you have lots of files, and lots of history, > > this combinatorial problem can sometimes bite at a bad time for the > > user of a tool trying to manage it all. > > In one of the talks by Linus on git I heard him recommending breaking very > large repositories into some smaller units to get better performance. > > Would it be something feasible in NetBSD? A single user requires > approximately what % of code from what he or she checks out to be actually > compiled and can there be 1 core and several optional repositories that > would increase this percentage. Just quoting the correct reference[1]: the way git works (tracking whole trees at a time, never single files), that ends up being very painful, because it's an "all or nothing" approach. So I'm hoping that if you guys are seriously considering git, you'd also split up the KDE repository so that it's not one single huge one, but with multiple smaller repositories I think, before we adopt a centralized repository (whether hg or git) this needs to be thought through. FreeBSD has been there done that when adopting SVN[2],[3] [1] https://lwn.net/Articles/246381/ [2] https://wiki.freebsd.org/VCSWhy [3] https://wiki.freebsd.org/GitDrawbacks
Re: cvs better than git?
On 2020-06-21 17:20, Andreas Krey wrote: On Sun, 21 Jun 2020 15:20:39 +, Johnny Billquist wrote: ... 40. And you can abbreviate as far as they stay unambiguous. And it's still not anything you would want to type at all. Yes, but. There are lots of ways to reference commits, like 'two before the current commit on this branch', but in the end, if you want to reference a random commit, you have a random address - a hash in git, a revision number in svn, and, well, nothing in cvs. What? I can't believe you are ignorant enough to not know that each file in cvs have a version number for each commit on it. Or refer to a revision at a certain point in time. ... I am still curious about how to manage well in git the scenario where you do have a central repository that holds the actual source of truth, and where you want to review and approve anything that gets committed. That depends on how you want to work - in git is the usual way that you commit your work, in reasonable steps, and then hand that out for review. For git itself this means posting the diffs of each commit to the git mailing list. (Unsurprisingly there are tools for that within git.) For the workflow in our company this means pushing your commits on a personal branch, creating a pull request, and discussing the changes inside that pull request and making changes until all reviewers are happy; then that is ready for integration. In git you usually don't review changes *before* you commit them. See.. That is, in my book (and not only mine) a serious broken pattern. You do not commit before reviewing. But ok, if that is how you work, then I guess there is not much I can learn from you in that area. Oh well. The gains of local repositories certainly diminish in the light of that, Not really. You wouldn't want to work with any central VCS once you're 250ms away from the server. I much rather do that than work according to some broken pattern. Anyway, I feel this is not really going anywhere, so I'll stop here. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: cvs better than git?
On Sun, 21 Jun 2020 15:20:39 +, Johnny Billquist wrote: ... > >40. And you can abbreviate as far as they stay unambiguous. > > And it's still not anything you would want to type at all. Yes, but. There are lots of ways to reference commits, like 'two before the current commit on this branch', but in the end, if you want to reference a random commit, you have a random address - a hash in git, a revision number in svn, and, well, nothing in cvs. ... > I am still curious about how to manage well in git the scenario where > you do have a central repository that holds the actual source of truth, > and where you want to review and approve anything that gets committed. That depends on how you want to work - in git is the usual way that you commit your work, in reasonable steps, and then hand that out for review. For git itself this means posting the diffs of each commit to the git mailing list. (Unsurprisingly there are tools for that within git.) For the workflow in our company this means pushing your commits on a personal branch, creating a pull request, and discussing the changes inside that pull request and making changes until all reviewers are happy; then that is ready for integration. In git you usually don't review changes *before* you commit them. > The gains of local repositories certainly diminish in the light of that, Not really. You wouldn't want to work with any central VCS once you're 250ms away from the server. > but it does add potential issues in keeping things in sync, getting > committed and shared. Yes, 'potential'. For a company setting, you avoid these by providing scripts for the standard workflow actions. You'll need - or at least want - these, independent of whether you work with clearcase, svn, or git, as soon as you don't all work on a single branch. > As I mentioned, we are using gerrit for this where > I work. But that is certainly not without a lot of pain. I've never seen gerrit up close, and my hearsay indicates it's a mixed bag. (We use hosted bitbucket, which so far is a pleasant experience.) PS: Reading up a bit on gerrit, it seems to use a patch-based model, with reworking the patches (i.e. amending commits). That can be daunting for beginners. > If you use something like github, then you will be using their systems > and mechanism for this, and if you are forced to switch, then this also > gets hit. Yes, but you don't lose your history or your current work; 'only' the open pull requests. With an hypothetical svnhub you'd also lose the history and have to set up a new server, totally invalidating all the dev's workspaces. With git, the transition can be much smoother, even in the case github goes bellyup instantaneously (e.g. you are kicked out as a customer). > Which was my point. It's not that you have "pure" git in the > first place. If you use some external service, you will also be > dependent on surrounding infrastructure provided, If you choose so. But it's the same with internal infrastructure. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: cvs better than git?
On 2020-06-21 17:07, Sad Clouds wrote: On Sun, 21 Jun 2020 10:32:32 -0400 g...@duzan.org wrote: On 2020-06-21 16:07, Rhialto wrote: On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote: I am still curious about how to manage well in git the scenario where you do have a central repository that holds the actual source of truth, and where you want to review and approve anything that gets committed. Let me point you to the hell that is called "Gerrit"... Example: https://review.opendev.org/ Like I said. We are using gerrit. It's not without a bunch of issues all on its own... :-) Any other options around with similar functionality? Johnny Our group at work uses Gerrit. We have had some trouble maintaining it, so we have been considering moving to Bitbucket, which already exists in the company. Bitbucket seems nice enough, though of course it is commercial. If I were looking for a solution today I would consider Phabricator/Differential, as it is open source, supports Mercurial, and appears decent enough. Gary Duzan What is the actual benefit of these tools? In a commercial environment I find them to be a complete distraction and it often results in people blocking you from committing changes due to various petty reasons. Ideally, you wouldn't need to manage anything, you trust your team members to use their own experience and commit correct and well tested code. You can still review the changes on their private branch, but you can easily do that on the command line - "svn diff --diff-cmd=meld ..." was the best review tool for me. Not talking about a specific tool, but the process then. There are multiple advantages by having code reviewed. First of all, noone is perfect. People make mistakes all the time, and having two people look at it already reduce silly errors significantly. Even when you have unit tests (which you should), there are still plenty of errors not caught by that. However, automatically running unit tests on all code to be committed, *before* it is committed, is also very valuable. For which you obviously need a process. Thirdly, it is also about spreading knowledge. It is never good to have just one person be familiar with some code. By having another person review things, you have at least two people who have a little deeper understanding of the code. There is absolutely nothing wrong with going back and reviewing already committed code later. But in all honestly, that's more often than not the exception rather than the rule. So I would never count on such a process. Finally, there are also the larger system type issues to be considered. Code might be perfectly fine in the local context, but others might also know a bit about other modules this code interacts with, and how those other modules work, and how they expect things to be used. And code reviews help catch those kind of issues as well. And it also helps from a system architecture point of view to make sure that the code is designed and works the way the overall design was intended, and that people don't drift off and start doing things in completely different ways which will break the overall design. When you are in projects with more than a couple of people writing and committing code, all of these issues have always been appearing, in my experience. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: cvs better than git?
On Sun, 21 Jun 2020 10:32:32 -0400 g...@duzan.org wrote: > > On 2020-06-21 16:07, Rhialto wrote: > >> On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote: > >>> I am still curious about how to manage well in git the scenario > >>> where you do > >>> have a central repository that holds the actual source of truth, > >>> and where > >>> you want to review and approve anything that gets committed. > >> > >> Let me point you to the hell that is called "Gerrit"... > >> Example: https://review.opendev.org/ > > > > Like I said. We are using gerrit. It's not without a bunch of > > issues all on its own... :-) > > > > Any other options around with similar functionality? > > > >Johnny > >Our group at work uses Gerrit. We have had some trouble > maintaining it, so we have been considering moving to Bitbucket, > which already exists in the company. Bitbucket seems nice enough, > though of course it is commercial. If I were looking for a solution > today I would consider Phabricator/Differential, as it is open > source, supports Mercurial, and appears decent enough. > > Gary Duzan What is the actual benefit of these tools? In a commercial environment I find them to be a complete distraction and it often results in people blocking you from committing changes due to various petty reasons. Ideally, you wouldn't need to manage anything, you trust your team members to use their own experience and commit correct and well tested code. You can still review the changes on their private branch, but you can easily do that on the command line - "svn diff --diff-cmd=meld ..." was the best review tool for me.
Re: cvs better than git?
> On Jun 21, 2020, at 10:32 AM, g...@duzan.org wrote: > > >> >>> On 2020-06-21 16:07, Rhialto wrote: >>> On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote: I am still curious about how to manage well in git the scenario where you do have a central repository that holds the actual source of truth, and where you want to review and approve anything that gets committed. >>> >>> Let me point you to the hell that is called "Gerrit"... >>> Example: https://review.opendev.org/ >> >> Like I said. We are using gerrit. It's not without a bunch of issues all >> on its own... :-) >> >> Any other options around with similar functionality? >> >> Johnny > > Our group at work uses Gerrit. We have had some trouble maintaining it, > so we have been considering moving to Bitbucket, which already exists > in the company. Bitbucket seems nice enough, though of course it is > commercial. If I were looking for a solution today I would consider > Phabricator/Differential, as it is open source, supports Mercurial, and > appears decent enough. > > Gary Duzan > > People like gitlab >
Re: cvs better than git?
> On 2020-06-21 16:07, Rhialto wrote: >> On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote: >>> I am still curious about how to manage well in git the scenario where >>> you do >>> have a central repository that holds the actual source of truth, and >>> where >>> you want to review and approve anything that gets committed. >> >> Let me point you to the hell that is called "Gerrit"... >> Example: https://review.opendev.org/ > > Like I said. We are using gerrit. It's not without a bunch of issues all > on its own... :-) > > Any other options around with similar functionality? > >Johnny Our group at work uses Gerrit. We have had some trouble maintaining it, so we have been considering moving to Bitbucket, which already exists in the company. Bitbucket seems nice enough, though of course it is commercial. If I were looking for a solution today I would consider Phabricator/Differential, as it is open source, supports Mercurial, and appears decent enough. Gary Duzan
Re: cvs better than git?
On 2020-06-21 16:07, Rhialto wrote: On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote: I am still curious about how to manage well in git the scenario where you do have a central repository that holds the actual source of truth, and where you want to review and approve anything that gets committed. Let me point you to the hell that is called "Gerrit"... Example: https://review.opendev.org/ Like I said. We are using gerrit. It's not without a bunch of issues all on its own... :-) Any other options around with similar functionality? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: cvs better than git?
On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote: > I am still curious about how to manage well in git the scenario where you do > have a central repository that holds the actual source of truth, and where > you want to review and approve anything that gets committed. Let me point you to the hell that is called "Gerrit"... Example: https://review.opendev.org/ -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: cvs better than git?
On 2020-06-21 14:27, Andreas Krey wrote: On Sun, 21 Jun 2020 12:07:00 +, Johnny Billquist wrote: ... simple operations, and yet I waste a day or two on git instead of just getting work done. For me a clear sign that the tool is wrong. 'one or two days' has a bit of a smell to it. It is a rather loose statement, yes. But last time I had it happen, in the end, it was three people trying to figure things out for most of one day before giving up. And it has happened more than once. I doubt I could ever give a totally accurate number for the time wasted, but it is obviously significant. ... obviously not meant for people to use on the command line. You do not have 20 character long hashes as arguments to something on a command line interface. 40. And you can abbreviate as far as they stay unambiguous. And it's still not anything you would want to type at all. ... Call it what you want. In the end, you still have a master somewhere. Which is the absolute truth of the work. And everyone else needs to sync with that. And anything going in there needs to be checked before accepted. The point being, regarding the usability of git and/or other VCSes in the review process? I am still curious about how to manage well in git the scenario where you do have a central repository that holds the actual source of truth, and where you want to review and approve anything that gets committed. The gains of local repositories certainly diminish in the light of that, but it does add potential issues in keeping things in sync, getting committed and shared. As I mentioned, we are using gerrit for this where I work. But that is certainly not without a lot of pain. If you use something like github, then you will be using their systems and mechanism for this, and if you are forced to switch, then this also gets hit. Which was my point. It's not that you have "pure" git in the first place. If you use some external service, you will also be dependent on surrounding infrastructure provided, which means that a move to some alternative comes with a cost. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: cvs better than git?
On Sun, 21 Jun 2020 12:07:00 +, Johnny Billquist wrote: ... > simple operations, and yet I waste a day or two on git instead of just > getting work done. For me a clear sign that the tool is wrong. 'one or two days' has a bit of a smell to it. ... > obviously not meant for people to use on the command line. You do not > have 20 character long hashes as arguments to something on a command > line interface. 40. And you can abbreviate as far as they stay unambiguous. ... > Call it what you want. In the end, you still have a master somewhere. > Which is the absolute truth of the work. And everyone else needs to sync > with that. And anything going in there needs to be checked before accepted. The point being, regarding the usability of git and/or other VCSes in the review process? - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: cvs better than git?
On 2020-06-21 10:57, Andreas Krey wrote: On Sun, 21 Jun 2020 00:03:54 +, Johnny Billquist wrote: ... Except when git refuses to do that, which I have had happen to me several times. git stash refuses (I can't even remember the error message right now, but something weird). I can't think of any nonobvious (like being in a conflicted merge already, or in a rebase) reasons why it should fail, but I might have internalized those cases so well that I subconsciously avoid them. Yeah. I suspect you either consciously or subconsciously avoids a whole bunch of things that can lead git into broken state. So then it's easy for you to say that you have never seen that, and cannot understand the problem. And of course it's not something easy, non-obvious. If it were, then it would be easily fixed, which it has not been. Next time I get there, I'll save the output from the commands, and try to remember sharing them with you, just for the amusement... Right before I go and wipe git yet again. And every time I manage to get there it has been extremely frustrating, because I know exactly what I want to do, and it is some extremely simple operations, and yet I waste a day or two on git instead of just getting work done. For me a clear sign that the tool is wrong. Which of course also leads on to the git pull refusing to work, and no matter how you fight it, it seems to have been impossible to resolve. Which is one of the scenarios I mention I've been in where in the end, even the "experts" gave up and just told me to wipe and start over. Perhaps let an actual expert look on them. (Yes, I know, they tend to not be available at that point in time, and few people are interested in later reproducing the situation.) I have obviously no desire at all to reproduce the situation, as I have better things to waste my paid time on. But when it has happened, the people who have tried looking at it have definitely many years of experience with git in all kind of ways, and are true git believers. Which obviously did not help. Don't you love typing in those long hashes to refer to specific versions? Non sequitur to the previous paragraph. Unless you're actually on a glass tty it's usually copy, and even that I don't need often. Definitely a non sequitur to the above. But you drifted on to how you only use the command line, which just reminded me of another thing with git I really dislike, especially on the command line. That thing was obviously not meant for people to use on the command line. You do not have 20 character long hashes as arguments to something on a command line interface. Yes, cut and paste becomes absolutely required. Which should tell you that command line is really bad. Basically, it seems like everyone is sooner or later giving up on command line, and start using some graphical tool to try to make sense of the git repository... Not me. The only gui tool I tried and kept using is 'gitk', mainly because it allows to see the current state of the commit graph much better than anything text-mode. Me: Everyone ends up using some gui tool to make sense of things. You: Not me. I only use one gui tool. So in which way is that "not using a gui tool"? And of course you want code reviews and the like before something gets committed to the central repository. '...gets merged into a blessed branch', more likely. The point being probably that 'commit' and 'to somewhere' are different things in DVCS. The distinction between 'patchset to review' and 'commits to make' blurs. Call it what you want. In the end, you still have a master somewhere. Which is the absolute truth of the work. And everyone else needs to sync with that. And anything going in there needs to be checked before accepted. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: cvs better than git?
On Sun, 21 Jun 2020 11:05:51 +0200 Andreas Krey wrote: > But I take objection at the 'seems'. You're arguing > that some - few - projects are too big for git, and > hence everybody should stay away from is. Even though > MS implemented VFS exactly to be able *use* git. > Absolutely not. There are many small and medium projects out there and if Git works for them, that is great. I'm not trying to persuade anyone to stay away from Git or Mercurial or anything else. There is no perfect VCS that will please everyone, but I find it interesting to hear why one VCS is better or worse than another and the use-cases that lead to that. Just because I have an opinion on something does not mean that I expect everyone else to agree with me.
Re: cvs better than git?
On Sat, 20 Jun 2020 16:52:16 +, Sad Clouds wrote: ... > Because let's face it, breaking up codebase into gazillions of smaller > repos is daft and not very user friendly. Neither is throwing unrelated things into a single repo. It's not easy to decide where to draw the line - what you do actually version and release separately gives a hint. ... > Git local repos seem cool up to a certain size, Our big one is 15G storage and 130.000 files, and that works mostly (we clone new workspaces from caches, not directly from the primary to take load off that). But I take objection at the 'seems'. You're arguing that some - few - projects are too big for git, and hence everybody should stay away from is. Even though MS implemented VFS exactly to be able *use* git. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: cvs better than git?
On Sun, 21 Jun 2020 00:03:54 +, Johnny Billquist wrote: ... > Except when git refuses to do that, which I have had happen to me > several times. git stash refuses (I can't even remember the error > message right now, but something weird). I can't think of any nonobvious (like being in a conflicted merge already, or in a rebase) reasons why it should fail, but I might have internalized those cases so well that I subconsciously avoid them. > Which of course also leads on > to the git pull refusing to work, and no matter how you fight it, it > seems to have been impossible to resolve. > Which is one of the scenarios I mention I've been in where in the end, > even the "experts" gave up and just told me to wipe and start over. Perhaps let an actual expert look on them. (Yes, I know, they tend to not be available at that point in time, and few people are interested in later reproducing the situation.) ... > Don't you love typing in those long hashes to refer to specific versions? Non sequitur to the previous paragraph. Unless you're actually on a glass tty it's usually copy, and even that I don't need often. > Basically, it seems like everyone is sooner or later giving up on > command line, and start using some graphical tool to try to make sense > of the git repository... Not me. The only gui tool I tried and kept using is 'gitk', mainly because it allows to see the current state of the commit graph much better than anything text-mode. > And of course you want code reviews and the like before something gets > committed to the central repository. '...gets merged into a blessed branch', more likely. The point being probably that 'commit' and 'to somewhere' are different things in DVCS. The distinction between 'patchset to review' and 'commits to make' blurs. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
