Le��30 nov. 2015 5:24 AM, "EuanM" <euanmee@gmail.com> a ��crit��:
>
> Is there anything stopping us adding one more dictionary to each
> Monticello commit?
>
> A key of commit ids and values of author name?

This dictionary is already there in the version metadata... The file that generates conflicts in git.

Thierry

> On 24 November 2015 at 06:55, stepharo <stepharo@free.fr> wrote:
> > +1
> >
> > And so far Monticello is much better that having delta because you can still
> > get a complete project without having to reconstruct the complete
> > snapshot from deltas. I could not imagine the amount of code we would have
> > lost else.
> > Veronica in her PhD built a crawler that reconstructs all the deltas based
> > on MC files. Now this is work.
> > Stef
> >
> > Le 23/11/15 17:02, Nicolas Cellier a ��crit :
> >
> > It's not Monticello per se. It's the backend (the server) which is too
> > naive.
> > The .mcz must be considered as a unit of exchange between the server (the
> > repository) and the client (the working copy). And please note that in
> > Monticello, it's not the only way to exchange data, it can also be a .mcd (a
> > diff).
> >
> > Nothing forces the server to store the .mcz as is. That's just a naive
> > implementation. Chris Muller demonstrated how to use a database (magma) as
> > backend...
> >
> > 2015-11-23 12:12 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
> >>
> >>
> >> > On 22 Nov 2015, at 20:12, EuanM <euanmee@gmail.com> wrote:
> >> >
> >> > Is there any reason against amending Monticello to store and save all
> >> > author's names?
> >>
> >> It does. *If* you have all the versions��� but doing anything with ���all the
> >> versions���
> >> is so slow (you need to download them, unpack them���) that we do not even
> >> have
> >> a tool to show the history of a method.
> >> (getting the oldest should be simpler, if you have complete history+this
> >> .mcz is
> >> there).
> >>
> >> Monticello is meant to be a system to save the complete history of a
> >> project
> >> (if you keep all the MCZ available), but the idea to save every tiny
> >> revision as
> >> a complete snapshot, zip compresses, makes it near impossible to do
> >> anything
> >> with the history in practice.
> >>
> >> With today disks, a practical SCM would allow anyone to have the
> >> *complete*
> >> history on the local disk. Monticello does now allow that in any practical
> >> way.
> >>
> >> >
> >> > Presumably, we'd also want a tool that could extract amnders' names
> >> > all the way back to the first commit of a package?
> >> >
> >> > How many on-line Monticello repositories are in common use?
> >> >
> >> > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3)
> >> >
> >> > Are there active administrators for each of those repositories that
> >> > would allow us to update the repositories to use the updated
> >> > Monticello?
> >> >
> >> > On 22 November 2015 at 15:42, Marcus Denker <marcus.denker@inria.fr>
> >> > wrote:
> >> >>
> >> >> On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk@gmail.com>
> >> >> wrote:
> >> >>
> >> >>
> >> >> 2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
> >> >>>
> >> >>> epicea data is not stored forever. It is seasion based and the shipped
> >> >>> image is
> >> >>> clean.
> >> >>
> >> >>
> >> >> But current source of this info is changes file (maybe sources). And I
> >> >> remember you planned to store current sources in image. And such
> >> >> information
> >> >> can be there too.
> >> >> Maybe I miss something?
> >> >>
> >> >>
> >> >> The original author is not really that much of information. And storing
> >> >> it
> >> >> for every method in the image would take space.
> >> >>
> >> >> As I said: the whole idea of using a source revision control system is
> >> >> that
> >> >> you have the *complete* history available, but
> >> >> not wasting RAM.
> >> >>
> >> >> Marcus
> >> >
> >>
> >>
> >
> >
>