max, maybe you want to create a test git repos with all the sources back to 1.0 :D and then we should record all changes into a local git-repos :) if you want to got back some versions you simply start fetching the missing objects from a central repos somewhere...
so far dreaming a bit best cami On 2012-03-06, at 20:01, Marcus Denker wrote: > > On Mar 6, 2012, at 7:30 PM, Max Leske wrote: > >> This may be a stupid question… (As far as I understand, condensing the >> changes is not the same) >> Why don't you increment the version number of the sources file to 1.1 and >> use a fresh changes file? >> > The sources file does not contain the sources and the changes just the > changes. (even though one could think so taking > the names into account.) > > The sources file containes the sources of ages ago (1.0), the .changes is "on > top of that". This means that the .sources > file contains a lot of code from classes and methods that have been removed > (like the changes), > as well as old versions. > > The .sources/.changes mechanism merges three responsabilties: > > 1) be a log of all edited code in case of a crash > 2) store the current source of the methods (when you ask a method for code, > it reads either from the .sources > (method not changed since 1.0) or from the .changes (method was changed). > 3) provide a history for all code > > And all that in 2 big files that one can only append to because? No idea, > actually... > > I personally think that it is a mistake today to merge all these into one > such basic mechanism. Especialy if > you look at how complex the code is in the image... it's actually amazing. > > When you do a #condenseSources (which is sadly broken right now), then it > generates a .sources > file with just the code in the current image. It would be interesting to see > how large that is. > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > >
