Inline and abridged. On Apr 20, 2011, at 2:00 PM, Germán Arduino <gardu...@gmail.com> wrote:
> 2011/4/20 Dale Henrichs <dhenr...@vmware.com>: >> >> It's just an added dimension of complexity ... not to mention the cost of >> converting existing development processes, tools, artifacts to the new >> system...it took Monticello nearly a decade to become commonly used:) > > A thing I not understand is why we need to go "file-based" if we are > already object based (several steps ahead)? There are a number of reasons. One is better interop with existing tools: many professionals will be parted from their tools only in death, and this is a barrier to using Smalltalk at work outside of niches where it was adopted early on. I would like a job with my Smalltalk, please and thank you:) > Sure! But, (I'm only asking) we couldn't using Git with objects? It's > only curiosity, not that I would like Git, eheh, I knew Github only > today! Well, we could do that. Git can version blobs. It just can't diff or merge them. And if you would also (as many professionals do) like to keep using your preferred text editor, you're out of luck. The Git (read: Linux kernel) model depends on merging code from the wild successively up through more and more trusted repositories until it makes it to Linus and the kernel. You can't do that unless you can merge changes from downstream seamlessly. So ultimately we would need a textual representation for code that plays better with the merge logic in popular SCM tools (e.g. the ordering in changesets is semantic, which doesn't work well when you merge, so load order and doits would have to be captured as metadata or specified explicitly in a manifest.) Does this help to describe the landscape a bit? > Germán. >
