2

This part of the documentation:

http://git-scm.com/book/en/v2/Getting-Started-Git-Basics

describes how git stores a full snapshot of the full filesystem/repository for each commit instead of tracking file changes.

I understand the concept but would like to understand it by example. I have therefore created a dummy SVN repository containing 8 revisions/checkins.

Now in SVN I do a "Update item to revision". E.g revision 4:

enter image description here

What happens is that my local svn repository automatically updates to the content of revision 4 (deletes/adds local content)

To me that seems exactly what happens in Git when a previous commit is checked out - from the local filesystem perspective.

Am I missing something or does Git and SVN not behave in the same way when it comes to how files are changes on disk when checking out previous versions/revisions of the codebase?

alroc
  • 27,574
  • 6
  • 51
  • 97
u123
  • 15,603
  • 58
  • 186
  • 303
  • good pointers: http://stackoverflow.com/a/8198287/6309, http://stackoverflow.com/q/5176225/6309: a snapshot in Git also entails that if the same content is present twice, it is stored only once. – VonC Dec 08 '14 at 12:29

2 Answers2

2

What happens is that my local svn repository automatically updates to the content of revision 4 (deletes/adds local content)

To me that seems exactly what happens in Git when a previous commit is checked out - from the local filesystem perspective.

And that's correct, it's just that git's internals are simpler and more useful.

does Git and SVN not behave in the same way when it comes to how files are changes on disk

Also correct: while so far as anyone's worktree is concerned git and svn have the same fundamental job, to put the content of any version anyone ever told it to care about to a worktree and take in new versions to care about, git's internal model is that it stores the versions directly. Whenever the payoff for packing up new content for compression looks like it'll be gratifying its object-access layer will do that under the hood, but the actual content tracking and source control never see that.

Community
  • 1
  • 1
jthill
  • 55,082
  • 5
  • 77
  • 137
-1

Git commit contains only changed/new files. Also it's linked to previous commit(s). That's how all other files can be found.

But old objects can be compressed in future for space optimization.

  • Ok but from a filesystem view you don't see any difference between Git/SVN when checking out a specific commit/revision (ignoring how its internally begin done)? – u123 Dec 08 '14 at 12:59
  • Git will find previous objects in .git dir and replace (delete/add) files changed between two revisions –  Dec 08 '14 at 13:04
  • The same happens in SVN when I update to a previous revision - files gets deleted/added/updated according to the change at that point. – u123 Dec 08 '14 at 13:07
  • The difference is that with `git` you do it locally, but `svn` need to fetch that files from server –  Dec 08 '14 at 13:12
  • yes but besides that the output generated on disk would be the same right? – u123 Dec 08 '14 at 14:48
  • 3
    @Russel This is incorrect. A commit in `git` contains the entire contents of the entire working directory (minus things that are ignored, or haven't been `git add`ed, of course), not just the stuff that changed. SVN, CVS, etc. work the way you describe - just storing the changes - but `git` stores snapshots of the project. – twalberg Dec 08 '14 at 17:13
  • @twalberg Save your keystrokes. This guy was a sock puppet, or was using sock puppets. – jub0bs Dec 09 '14 at 11:56