Poll

What's your favorite version control system?

git
87 (68%)
mercurial
5 (3.9%)
svn
19 (14.8%)
cvs
1 (0.8%)
other
16 (12.5%)

Total Members Voted: 128

Author Topic: Version Control  (Read 5044 times)

0 Members and 1 Guest are viewing this topic.

Online techman-001

  • Frequent Contributor
  • **
  • Posts: 650
  • Country: au
  • Electronics technician for the last 47 years
Re: Version Control
« Reply #75 on: January 21, 2020, 07:55:11 pm »

Now I'm confused .....
 Are you ranting because you have just discovered that Fossil has everything GIT has, or are you ranting because you have found that Fossil is different to GIT
I think it's the latter. I'm literally shaking and triggered by their insistence on preserving accurate history over creating a fake one which is convenient to review and debug ;D

I sympathize completely and I'd send you a nice cuddly stuffed Fossil mascot to hug in your safe space if I could  :-+

I can only imagine your anger as you read thru the Fossil treatise on REBASING and encountered statements such as "Rebasing is the same as lying" or "Honorable writers adjust their narrative to fit history. Rebase adjusts history to fit the narrative."

What's really scary is the possibility that one day GIT might fix their weak history display capabilities and give their users the ability to switch back and forth between those instances where a simplified display is desirable and edifying and one showing the real, complete, messy history for cases where detail and accuracy are more important ?

My opinions only and you know I always enjoy your posts :)

Offline bd139

  • Super Contributor
  • ***
  • Posts: 15021
  • Country: gb
Re: Version Control
« Reply #76 on: January 21, 2020, 08:04:16 pm »
You might want to use svn for that  :-DD
 

Online techman-001

  • Frequent Contributor
  • **
  • Posts: 650
  • Country: au
  • Electronics technician for the last 47 years
Re: Version Control
« Reply #77 on: January 21, 2020, 08:07:08 pm »
I'll make some kind of summary/comment of the results and what has been discussed here when we reach ~100 votes.

That could be a while, or never because it's looking like only 60 - 70 posters among the hundreds of thousands on this forum actually use a SCM.

To most Github users, I suspect GIT is just a downloader.

Offline bsudbrink

  • Frequent Contributor
  • **
  • Posts: 406
  • Country: us
Re: Version Control
« Reply #78 on: January 21, 2020, 08:11:26 pm »
Perforce
 

Offline magic

  • Super Contributor
  • ***
  • Posts: 2156
  • Country: pl
Re: Version Control
« Reply #79 on: January 21, 2020, 10:42:42 pm »
I wonder how fossil fanboys do review?

Say I'm supposed to review a feature to be merged into master. In the usual git-liar workflow, I get a pull request with a bunch of commits which implement the feature in logical steps. I can understand what each commit does, analyze it in isolation, verify that the software builds and works between the commits so no breakage will occur if somebody runs bisect in the future.

And without lying? You guys want me to review the whole branch, including commits like "fix a typo which broke the build" and "address the remarks of Johny Grammar Nazi"? Or maybe look at the Big Diff and try to make sense of all of it? I think I would rather be lied to :P
 

Online dunkemhigh

  • Super Contributor
  • ***
  • Posts: 1915
Re: Version Control
« Reply #80 on: January 21, 2020, 11:01:36 pm »
Not a fan boy (only briefly looked at it) but my understanding is that if you really want the compressed version you can allow that. It's just that the whole truth version is still there if someone cares to look at it - it can't be actually removed, just hidden.
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 15021
  • Country: gb
Re: Version Control
« Reply #81 on: January 21, 2020, 11:27:02 pm »
I wonder how fossil fanboys do review?

Say I'm supposed to review a feature to be merged into master. In the usual git-liar workflow, I get a pull request with a bunch of commits which implement the feature in logical steps. I can understand what each commit does, analyze it in isolation, verify that the software builds and works between the commits so no breakage will occur if somebody runs bisect in the future.

And without lying? You guys want me to review the whole branch, including commits like "fix a typo which broke the build" and "address the remarks of Johny Grammar Nazi"? Or maybe look at the Big Diff and try to make sense of all of it? I think I would rather be lied to :P

Code review is a human issue. No tool is any good there despite the marketing. I know that because I’ve watched people hand jobbing each other’s PR’s through because they share a pint after work occasionally. I’ve watched people miss some pretty obvious shit. My favourite being the one where there was a non terminal loop iterating through dates which took out 45 production machines running 50 threads each in under twenty seconds from deployment and caused a massive SLA pay out. All because a dingbat was a bit hung over that day.

And then there’s the issue of the size or scope of a change. When that rebased and squashed PR for a feature branch comes in at 20,000 LOC no one is going to give a shit about it. Flag it through like the chequered flag at the end of a Grand Prix.

And on top of that does anyone know enough about what they’re doing to rationalise every decision made? They need to know the business domain and the programming language and the entire system well for this to be productive.

Ergo we have to ask should we even bother?

Yes we should but don’t formalise it. Drag a random colleague over and sit down and go through it together in person on your branch. Push it to someone else to get feedback on the other side of the planet. Get a QA guy to have a look at your branch. Get the build system and full integration test feedback in your branch (you are building your branches in your CI/CD platform aren’t you?). Once confidence is attained, then merge it and deploy it.

None of that is VCS or product specific.

What is the value of a PR? Near nothing.

I find it’s better to review the humans. Good programmers do the above implicitly and self organise.

Edit: for ref I was the dingbat who left the non terminal loop and it was flagged through by someone who actually accepted the review 11 seconds after I opened the PR...
« Last Edit: January 21, 2020, 11:29:56 pm by bd139 »
 
The following users thanked this post: Tepe

Offline olkipukki

  • Frequent Contributor
  • **
  • Posts: 447
  • Country: 00
Re: Version Control
« Reply #82 on: January 21, 2020, 11:29:44 pm »
And? Storage is cheap!
Really? You never met guys who estimated a low 5 digital expense in Excel that will last decade or so in AWS, but a recent bill in mid-6 figures "shock the nation"?  >:D
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 15021
  • Country: gb
Re: Version Control
« Reply #83 on: January 21, 2020, 11:36:17 pm »
And? Storage is cheap!
Really? You never met guys who estimated a low 5 digital expense in Excel that will last decade or so in AWS, but a recent bill in mid-6 figures "shock the nation"?  >:D

Aka Thursday for me  :-DD. It’s not about saving money but shifting capex to opex. No one has worked that out yet.
 

Offline olkipukki

  • Frequent Contributor
  • **
  • Posts: 447
  • Country: 00
Re: Version Control
« Reply #84 on: January 21, 2020, 11:36:50 pm »
I stick large binaries in amazon S3. You can enable bucket versioning.

How big your "large binaries" and a link to AWS?

I only put a public stuff and works fine with CloudFront.
The versioning save my a** a few times after mess I did there.  :-+



 

Online techman-001

  • Frequent Contributor
  • **
  • Posts: 650
  • Country: au
  • Electronics technician for the last 47 years
Re: Version Control
« Reply #85 on: January 22, 2020, 02:34:02 am »
I wonder how fossil fanboys do review?

Say I'm supposed to review a feature to be merged into master. In the usual git-liar workflow, I get a pull request with a bunch of commits which implement the feature in logical steps. I can understand what each commit does, analyze it in isolation, verify that the software builds and works between the commits so no breakage will occur if somebody runs bisect in the future.

And without lying? You guys want me to review the whole branch, including commits like "fix a typo which broke the build" and "address the remarks of Johny Grammar Nazi"? Or maybe look at the Big Diff and try to make sense of all of it? I think I would rather be lied to :P

Fanboys ?

The Tcl/Tk project uses Fossil, and it's a rather large project with a decent-sized community, I suppose they manage reviews one way or another ?
http://core.tcl.tk/tk/timeline?y=ci




Offline bd139

  • Super Contributor
  • ***
  • Posts: 15021
  • Country: gb
Re: Version Control
« Reply #86 on: January 22, 2020, 07:58:44 am »
I stick large binaries in amazon S3. You can enable bucket versioning.

How big your "large binaries" and a link to AWS?

I only put a public stuff and works fine with CloudFront.
The versioning save my a** a few times after mess I did there.  :-+

Dependencies ~400Mb a go. VM images 8-20Gb a go. Link varies. I’m happy on 76mbits down
 

Offline sleemanj

  • Super Contributor
  • ***
  • Posts: 2499
  • Country: nz
  • Professional tightwad.
    • The electronics hobby components I sell.
Re: Version Control
« Reply #87 on: January 22, 2020, 08:28:29 am »
The Tcl/Tk project

TIL that Tcl/Tk still exists!

Seriously I thought that would be deader than CVS at this point!
~~~
EEVBlog Members - get yourself 10% discount off all my electronic components for sale just use the Buy Direct links and use Coupon Code "eevblog" during checkout.  Shipping from New Zealand, international orders welcome :-)
 

Online dunkemhigh

  • Super Contributor
  • ***
  • Posts: 1915
Re: Version Control
« Reply #88 on: January 23, 2020, 12:01:00 am »
I stick large binaries in amazon S3. You can enable bucket versioning.

Doesn't that (bucket versioning) essentially convert git/svn/fossil or whatever back to VCS badness, specifically file versioning as opposed to project versioning? That is, to go back to version n you need version n of the locally held files plus version m of the bucketed files.
 

Offline guenthert

  • Frequent Contributor
  • **
  • Posts: 388
  • Country: us
Re: Version Control
« Reply #89 on: January 23, 2020, 01:14:39 am »
Yeah that's just Linus' attitude.
Showing Nvidia, who treated Linux as second-class citizen, the finger got him then lot of sympathy.  And it seemed to have helped.

RMS complained, then Larry at bitseeker got the ass then it got fixed: https://marc.info/?l=linux-kernel&m=103457829307456&w=2

Bitkeeper is dead.
  Not sure what you mean by 'dead' there.  I don't know how viable Larry's business is, but they're still getting pretty a penny from the company I work for (support contract -- the actual software is FOSS now).  We're using it since the code base is old, quite large and getting it (and more importantly the history of code changes) into git was deemed impractical and not worth the effort a few years back.  Most of the engineers would probably be content using git, but some swear by bitkeeper.  At the very least, we had little trouble with it and Larry (regardless of his reputation otherwise) has been very responsive and competent in the few cases there were questions.



I love Linux flamewars!  :-DD
So much that you attempt to start one with half-truth and out-of-context quotations?
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 15021
  • Country: gb
Re: Version Control
« Reply #90 on: January 23, 2020, 08:34:50 am »
Linus’ attitude generally is consistent with that photo. I know the context. It was intended to show the attitude. I mean have you seen the outbursts on LKML?

Bitkeeper is dead. It’s a niche product eaten by momentum. 99% of people I have worked with have never heard of it. Compare Perforce and RCS which are known universally. Even if the latter is dead.

So half truths, no. Out of context, no.

I stick large binaries in amazon S3. You can enable bucket versioning.

Doesn't that (bucket versioning) essentially convert git/svn/fossil or whatever back to VCS badness, specifically file versioning as opposed to project versioning? That is, to go back to version n you need version n of the locally held files plus version m of the bucketed files.

Depends on your workflow. If you have to version large binaries (Gb in size) I haven’t found a better option.
 

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1111
  • Country: gb
  • Embedded stuff
Re: Version Control
« Reply #91 on: January 23, 2020, 11:40:20 am »
I wonder how many people use AllChange, which I was forced to use recently. It wasn't designed specifically for software, and naturally it's a real pain in the ass to use.
Bob
"All you said is just a bunch of opinions."
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 15021
  • Country: gb
Re: Version Control
« Reply #92 on: January 23, 2020, 11:55:50 am »
Seen that. That's plainly aimed at upper management not end users
 

Offline Jan Audio

  • Frequent Contributor
  • **
  • Posts: 455
  • Country: nl
Re: Version Control
« Reply #93 on: January 25, 2020, 05:25:29 pm »
So i searched what GIT is and found out it is a software-application where in you save your source codes ?
ha ha ha
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 985
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: Version Control
« Reply #94 on: February 04, 2020, 07:01:00 am »
So i searched what GIT is and found out it is a software-application where in you save your source codes ?
ha ha ha

That's a joke right...?  :-//
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline frogg

  • Regular Contributor
  • *
  • Posts: 114
  • Country: us
Re: Version Control
« Reply #95 on: February 12, 2020, 09:16:06 pm »
I'm personally a fan of git, but for developers using windows, I think subversion is attractive.
 

Online dunkemhigh

  • Super Contributor
  • ***
  • Posts: 1915
Re: Version Control
« Reply #96 on: February 12, 2020, 09:24:39 pm »
I am intrigued! Why would Windows make subversion more attractive than git?
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 15021
  • Country: gb
Re: Version Control
« Reply #97 on: February 12, 2020, 09:30:53 pm »
TortoiseSVN. UI that isn't shit and mortals can operate.

I slightly hoped this thread had died. Oh well.  :-DD
 

Online dunkemhigh

  • Super Contributor
  • ***
  • Posts: 1915
Re: Version Control
« Reply #98 on: February 12, 2020, 09:47:24 pm »
But there is Tortoisegit, and TortoiseHg.
 

Offline nigelwright7557

  • Frequent Contributor
  • **
  • Posts: 255
  • Country: gb
    • Murton-Pike Systems
Re: Version Control
« Reply #99 on: February 12, 2020, 09:52:22 pm »
I have always tried to be careful about data structures in programs in regards version control.
I tend to leave a few empty spaces in the structures in case i need to add more later on.
The empty items are always zeroed on creation to ensure they are initialised.
Another thing I do is if I really have to add a variable it is saved to disc in its own file rather than mess with files already there.
When it was impossible to do anything else but add a new structure I have always added a "legacy update" function for it so newer versions of software can convert older versions.
This means i tend not to keep old versions of the software.
I have used GIT a couple of times but never found a reason to get the old versions back.
So what is more important to me is not losing any data and so I carefully back up to back drive, flash drives and DVD's.
I keep one flash drive in the car in case of fire.


PCBCAD51/PCBCAD360/PCBCAD720 PCB design software https://www.murtonpikesystems.co.uk
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf