How SVN works wrt copies of versions

[Tim Newsom]

I trimmed the subject line....

EdorFaus:
Thank you for correcting me.  =)
I have never seen the last commited verison in the local working directory
structure so I will have to check that out and see where its located.

--Tim.

On 12/2/06, EdorFaus <edorfaus at xepher.net> wrote:
>
> On 11/30/06, Tin Newsom <cephdon at gmail.com> wrote:
> <snip>
> > If you are keeping a copy of the current versions locally then diffing
> and
> > sending only the diffs would be easy... but to my knowledge svn only
> keeps
> > the diffs between versions at the repository. Someone who knowns please
>
> As far as I know, this is essentially correct - the repository contains
> the
> original file, and the diff for each version since then. This is,
> afterall,
> enough to recreate any version.
>
> > correct me.  If I understand what you are saying and based on my
> > knowledge...
> > You either keep an old version for diffing purposes and replace it with
> the
> > current version when you do the commit.  All changes happen to the
> original
> > not the "old copy"
>
> I believe this is exactly what svn does. It certainly keeps a copy of the
> last-committed (or updated-to) version in every working copy, along with
> the
> version being worked on. This allows it to do various things while
> offline.
>
> <snip>
> > My understanding of svn is that it transmits the entire file and the svn
> > server does the diff and only stores the differences between the files
> at
> > the repository.  I could be wrong about that though.
>
> No, but I believe this is how CVS works - SVN on the other hand only
> transmits
> the diffs in either direction, which is one of its selling points over CVS
> -
> iirc one of the things the SVN developers didn't like about CVS that
> caused
> them to make SVN in the first place.
> (Note: this is from my admittedly faulty memory, so might not be correct.)
>
> >
> > If you don't keep a repository locally then one way or another you will
> have
> > to obtain a copy of the old version in order to just sync changes
> somehow..
>
> This being, I believe, one of the main reasons SVN does keep a copy (of
> the
> latest-known-committed version) locally.
>
> Some other good reasons are things SVN can then do offline, e.g.
>         - generating diffs (what exactly did I change this time?)
>         - reverting a file (nono, that's no good, let me start over...)
>
> It can then also more easily update the working copy with new code from
> the
> repository, by seeing local diffs vs diffs in the repository.
>
> It only keeps one previous version in the working copy though, so for
> comparing with or reverting to earlier versions, it must still be online.
>
> >
> > Its an interesting thought.. does anyone know for sure if SVN sends back
> > only the changes and how it does that if it doesn't fetch the previous
> > version for comparison?
>
> See above. :)
>
> Just FYI, that it keeps a copy of the last version locally is something
> I've
> gotten quite familiar with through the use of grep... When I want to find
> something in the working copy, I usually  grep whatever | grep -v .svn  to
> avoid getting duplicates or finding things I've already changed locally :P
>
> >
> > --Tim
> >
> > btw.. I tend to over explain things so if I don't go far enough please
> ask
> > me (I am trying to cut back)  ;-)
> > Also, feel free to correct me if I state something wrong.. I like to be
> > correct in my understanding and if I don't have all the necessary
> > information I would like to know what I am missing out on.  ;-)
> <snip>
>
> Seconded. (iow, please apply the same to me.)
>
> --EdorFaus
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
>



-- 
-- Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20061202/e391e6a3/attachment.htm