|
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.
|
|
|
|
|
I'm still trying to love/like TFS.
It works, but I don't like it (or found any reasons to like it).
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
There's nothing inherently better in GIT compared to other modern source control systems.
It does what it advertised to do.
The 2 models are just different (centralised vs distributed)
I've worked with SourceSafe, RCS, CVS, SVN, GIT and now Team Foundation.
I came to love/hate git; mostly because it's so cryptic.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
The part that had me confused is that ultimately, all code *must* go back to the main server - just like SVN. What I did not comprehend is that when you pull a project from a GIT repo it's almost as if you copied the repo to your local machine. Once you push your changes back to the server, the magic of software kicks in, there is smoke and flashes of light and it all gets put back together.
I'm not sure if that justifies hyperventilating over GIT, but I understand the subtle difference now.
as other's have commented, it was born of distributed open source development. I live in a proprietary internal network with fiber everywhere, so I just did not see the "glowing" points for GIT. At the end of the day, it's just another source control system.
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: 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.
I say this as a dude who used SVN for years...
- Git is awesome.
- Old crusty people refuse change and to continue learning.
- People need to embrace distributed concepts if they want to belong to the future.
Now, as far as why you care today, as in right now. This is really a conversation between centralized vs distributed. You can replace SVN with anything centralized.
- Unlike with SVN, you can be 100% offline and still commit code you work on. Yeah sure, you can set up a local SVN server on your home network, but let's be real. This mean, if you commute to work on a train, you can code away and make commits. Then push them to a remote later on. If you never go outside, less of an issue I guess.
- Run queries and searches against your entire repo's history, locally and quickly.
- Run hooks to gate/guard your code before it ever hits the real repository. Yeah sure, you can have staging/feature branches in both Git and SVN, but with SVN it's still in the remote repo.
- Under the hood, git diffs commits more efficiently. I don't have evidence for this so it's anecdotal. But, from years of using it, it just feels quicker.
- I haven't used SVN in a while, so maybe this is moot, but with Git you have Git LFS. Google it.
- You should be making frequent commits to code. SVN is too slow for this. Large commits are terrible for maintenance. Anyone working in a large team knows this.
- Git is profoundly better at handling branches and deltas than SVN. Granted, I haven't used SVN in years... maybe it's better at it now... maybe. I don't know.
Anyone on CP saying keep with SVN, I can promise you still uses jQuery or VB, sans a few. And there are people (except for one, shout out to Ravi) who will argue all day long about how they think they are experts in their choice of version control, but they can't read a post or explain anything simply. Point is, don't trust CP to give you the best info always.
Oh, and sorry, if I sound jaded. It's not you or your post, I promise. I'm just old and cranky and really tired of having to deal with certain types of peeps, that's all. 
Jeremy Falcon
modified 13-Feb-24 9:09am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
