|
I know a company in India which is moving chips from general to particular.
They are designing chips for very specific purposes, almost with that particular instruction set (plus a small delta, maybe). They aim to lower memory and power consumption ... and more importantly, cost.
modified 13-Feb-24 22:07pm.
|
|
|
|
|
So, as a side project, I've been delving into the git source control world (triggered by Visual Studio incorporating it), and I'm smelling something nasty. As in, what's the point, other than preference?
I've insisted all of my development projects be in source control since the mid 80s. Back then, we were heavily developing on VMS, the version control system was CMS. I'm not sure back then we had the concept of branches and what not, but we could tag the code base for a specific release. I ran into one developer who kept his changes as file versions - it's a VMS thing. All it took was one purge command to lose ALL of the history.. shudder. Anyway....
So in the years to follow, I've motored through PVCS, ClearCase (shudder), VSS and SVN. After VSS burned me badly (there are many unflattering stories out there) due to a network outage, I transitioned all of my source control to svn. Supports concurrent development, tags, branches and merging and is far more robust than VSS. This would be about 15 years ago or so.
Along comes this git upstart. And all of the comparisons between it and svn generally say git is better for concurrent development, blah blah blah. Oh and it's a distributed model. And it allows for branching, etc.
Just like SVN.
Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me.
Appreciate your thoughts.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
In the past year or so, at work, we moved to Git from SVN for all of our work.
Is it better?
I can't see anything that it does better than SVN.
Is it worse?
I can't see anything that it does worse than SVN.
Why use it?
Github has some nice features, although I will admit that I actually found it easier to navigate the commit history through TortoiseSVN, but I think that's partly a learning process for me and the Github UI is very poorly designed in places.
So if you like SVN stick with it, but it's always useful to have some experience of something like Git so that you can understand what other people are talking about when they mention "pull requests" etc.(another poorly named feature in Git)
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
I'm just trying to understand the FUD pushing git.
Where does your source code live?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
The source code lives on remote servers and locally - we have local repositories we work from and we then push to, pull from, fetch from, merge to the Git remote server repositories.
We clone from the remote repositories to local repositories and work on the local repositories.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
see my last comment - I think I see the big difference between GIT and SVN. GIT allows *all* work locally and then will put it back together on the backend, where that might be.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
When we were using SVN, I still have it on my local machine, we could do all the work locally too.
Perhaps an advantage of Git, which I missed is the concept of the PR (Pull Request).
With SVN we were able to commit to trunk without any sort of approval.
So I could get changes through to production without anyone else seeing the changes.
With Git nothing get's merged into Main unless it has been code reviewed and the PR has been approved.
This is a really useful safety net meaning at least one other person has looked at our changes before they are allowed to be merged into Main/Trunk.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
With Git you don't just have all the code on your local machine, you also have (or can have) all the branches, versions and tags on the local machine. That way you can compare or even revert code with any prior version without connecting a centralized server. Now when you want to share your changes, you can connect and push to say GitHub and pull to get changes from other users.
Branching in Git is also more lightweight since it isn't a full copy of the code base.
BTW, while PRs are useful and desirable when working with other developers, they are a feature of online git services like Github and Gitlab not Git itself. Depending on your settings/configuration, you CAN push changes to main (trunk) without anybody seeing it first.
|
|
|
|
|
SourceTree (if it's still around) had a pretty nice and buttony UI.
Web Git is maybe also a bit different than Azure DevOps on-prem Git. Not sure. But ADO traversal of history (or VS) works pretty decent depending on what you're after. May need a VS extension, I can't recall if it's built-in or not.
|
|
|
|
|
For me, one of the bigger advantages is, because I have copies of the repository locally, it makes it easier for me to undo history and rebuild. Suppose, for instance, that I added in changes to a configuration file that I didn't want to. With git, it's easy for me to undo that item. This may not seem like a big deal, but it really is. What this gives me is the ability to remove that item, and rebuild an application from any commit after that point; and the configuration entry will be gone.
|
|
|
|
|
SVN allows local copies of repositories too.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
It's not quite the same. Changes are stored as deltas locally with GIT. So, everything you have is local. The central server is the accumulation point of these deltas. Now try the second part of what I said - undo a history item, and then rebuild any check in from that point. GIT makes this relatively trivial.
|
|
|
|
|
I don't think we ever had issue with that with SVN and local copies, but it may be that I am not understanding you and that you know this is not possible with SVN.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
The local copy part makes the remove historical commit trivial.
|
|
|
|
|
Keep in mind, I haven't used SVN in years. Maybe things change...
But, what SVN stores locally and what Git stores locally are not the same thing. SVN is more akin to metadata (over simplification of course) whereas Git stores the actual - same exact thing - repo. There's zero difference. It's all local. Which is to say, if I need to completely update/rewrite history locally, or do whatever, I can make sure remotely will have the same exact changes (with no extra commits, etc.).
It's been my experience that in SVN land, working with history is not a concept peeps care about, just make a new commit and who cares what history looks like. But, when working in a team, where some dev screws something up, it's nice to be able to clean things up when you need it. And IMO having a clean history is nice if you ever need to do any code investigation.
So, do you have need to worry about it often? Nope. I hope not.  But, it's nice to have when you do need it.
Jeremy Falcon
|
|
|
|
|
Jeremy - this smells like a branch? I'm just not seeing the difference other than git renaming basic source code control concepts.
Wait, see my post at the end of the comment section... I think I might have had an epiphany. Might be gas though.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: Jeremy - this smells like a branch?
Talking about working with history. That's not the same thing as a branch. What happens if history gets messed up after a branch is merged for instance?
charlieg wrote: Wait, see my post at the end of the comment section... I think I might have had an epiphany. Might be gas though.
Me go check it out...
Jeremy Falcon
|
|
|
|
|
let me know.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
"stored as deltas locally"
This doesn't smell right.
|
|
|
|
|
When your repo is not too big SVN will be fine, we had problems however with large repo's when we tried to do a "rollback" to a previous state, it would not work and threw lots of errors.
We are very pleased with Git, after going through a painful learning curve of course 
|
|
|
|
|
RickZeeland wrote: We are very pleased with Git, after going through a painful learning curve of course
And that's the real reason you find some people reject it... they don't want to learn.
Jeremy Falcon
|
|
|
|
|
With the right GUI it's easy. I love SmartGit for daily operation and Sourcetree for the amazing log viewer.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
Not to mention, I remember using TortoiseSVN back in the day. Its repo viewer was slow. But, then again, it had to make remote calls for everything.
Jeremy Falcon
|
|
|
|
|
Don't knock the hard heads, they kept the boiler going for the NoSQL train to run!
And the big boys gave them a curtain to hide behind.
"No, I'm not being lazy! I'm being like [a mega company who uses doc store]!"
|
|
|
|
|
CMS is still the best, other than (I'm guessing) integration with VS.
TFS is best when using VS.
Git is unusable, it lacks features which are what make CMS and TFS the best. It is to be hoped that those features will be added to Git.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
