[squeak-dev] [ANN] SqueakSVN
Locked
12
12
[squeak-dev] [ANN] SqueakSVN
 
|
Hi list,
I am very proud to announce "SqueakSVN". SqueakSVN is our last bachelor project and joins Squeak with version control offered by Subversion. Squeak developers take advantage of team programming and the benefits of Subversion's growing popularity and support. More details can be found on our web pages. - Project Description: http://www.swa.hpi.uni-potsdam.de/projects/ssvn/index.html - Source Code Download: http://www.swa.hpi.uni-potsdam.de/projects/ssvn/media/SqueakSVN.sar - Demonstration Video: http://www.swa.hpi.uni-potsdam.de/projects/ssvn/media/ssvn_en.mp4 Best Regards, Michael Perscheid on behalf of the Software Architecture Group Hasso-Plattner-Institut, Potsdam |
|
|
Looks interesting.
Congratulations. Michael Perscheid escribió: > Hi list, > > I am very proud to announce "SqueakSVN". > > SqueakSVN is our last bachelor project and joins Squeak with version > control offered by Subversion. Squeak developers take advantage of > team programming and the benefits of Subversion's growing popularity > and support. > > More details can be found on our web pages. > > - Project Description: > http://www.swa.hpi.uni-potsdam.de/projects/ssvn/index.html > > - Source Code Download: > http://www.swa.hpi.uni-potsdam.de/projects/ssvn/media/SqueakSVN.sar > > - Demonstration Video: > http://www.swa.hpi.uni-potsdam.de/projects/ssvn/media/ssvn_en.mp4 > > Best Regards, > > Michael Perscheid > on behalf of the Software Architecture Group > Hasso-Plattner-Institut, Potsdam > |
[squeak-dev] Re: [ANN] SqueakSVN
|
|
In reply to this post by Michael Perscheid
Hi -
I'm trying to use SqueakSVN and I'm not getting very far. The SVN repository is hosted at https://dev.qwaq.com/svn/SqueakSVN (and I've created it before I tried to use it). Obviously this site is also password protected. When I try to "Create Project" from SqueakSVN project browser I use the following settings: Project name: SqueakSVNTest Repository URL: https://dev.qwaq.com/svn/SqueakSVN Working copy: C:\SqueakSVN The only response I get is "Repository does not exist" although the repository URL works fine if I use it in the browser. I also tried a URL of the form https://user:pass@.../svn/SqueakSVN with the same response. Any ideas? Thanks, - Andreas Michael Perscheid wrote: > Hi list, > > I am very proud to announce "SqueakSVN". > > SqueakSVN is our last bachelor project and joins Squeak with version > control offered by Subversion. Squeak developers take advantage of team > programming and the benefits of Subversion's growing popularity and > support. > > More details can be found on our web pages. > > - Project Description: > http://www.swa.hpi.uni-potsdam.de/projects/ssvn/index.html > > - Source Code Download: > http://www.swa.hpi.uni-potsdam.de/projects/ssvn/media/SqueakSVN.sar > > - Demonstration Video: > http://www.swa.hpi.uni-potsdam.de/projects/ssvn/media/ssvn_en.mp4 > > Best Regards, > > Michael Perscheid > on behalf of the Software Architecture Group > Hasso-Plattner-Institut, Potsdam > > |
Re: [squeak-dev] Re: [ANN] SqueakSVN
|
|
Hi Andreas,
unfortunately SqueakSVN currently does not support https-based repositories. But repositories using the http, file or svn protocol should work fine. Robert On Sep 12, 2008, at 11:14 AM, Andreas Raab wrote: > Hi - > > I'm trying to use SqueakSVN and I'm not getting very far. The SVN > repository is hosted at https://dev.qwaq.com/svn/SqueakSVN (and I've > created it before I tried to use it). Obviously this site is also > password protected. When I try to "Create Project" from SqueakSVN > project browser I use the following settings: > > Project name: SqueakSVNTest > Repository URL: https://dev.qwaq.com/svn/SqueakSVN > Working copy: C:\SqueakSVN > > The only response I get is "Repository does not exist" although the > repository URL works fine if I use it in the browser. I also tried a > URL of the form https://user:pass@.../svn/SqueakSVN with > the same response. > > Any ideas? > > Thanks, > - Andreas > > Michael Perscheid wrote: >> Hi list, >> I am very proud to announce "SqueakSVN". >> SqueakSVN is our last bachelor project and joins Squeak with >> version control offered by Subversion. Squeak developers take >> advantage of team programming and the benefits of Subversion's >> growing popularity and support. >> More details can be found on our web pages. >> - Project Description: >> http://www.swa.hpi.uni-potsdam.de/projects/ssvn/index.html >> - Source Code Download: >> http://www.swa.hpi.uni-potsdam.de/projects/ssvn/media/SqueakSVN.sar >> - Demonstration Video: http://www.swa.hpi.uni-potsdam.de/projects/ssvn/media/ssvn_en.mp4 >> Best Regards, >> Michael Perscheid >> on behalf of the Software Architecture Group >> Hasso-Plattner-Institut, Potsdam > > |
[squeak-dev] Re: [ANN] SqueakSVN
|
|
In reply to this post by Michael Perscheid
Michael Perscheid a écrit :
> Hi list, > > I am very proud to announce "SqueakSVN". > > SqueakSVN is our last bachelor project and joins Squeak with version > control offered by Subversion. Squeak developers take advantage of team > programming and the benefits of Subversion's growing popularity and > support. > Nice ! Could you use a SVN repository as a monticello repository ? -- Serge Stinckwich Smalltalkers do: [:it | All with: Class, (And love: it)] http://blog.doesnotunderstand.org/ |
Re: [squeak-dev] [ANN] SqueakSVN
|
|
In reply to this post by Giuseppe
What I really like in SqueakSVN is an integration of repository
management directly into a browser. If other tools like Monticello would follow the example, life for us poor coders would be much easier, IMHO. Not to mention us who need to switch daily from different dialects. Code repository management directly from browser is for instance one of strengths of VisualWorks over Squeak. And as SqueakSVN guys demonstrated, this is not too hard to introduce in Squeak as well. This also raises another question: isn't a Squeak problem more usability of existing code management tools than their fundamentals? Just few my thoughts.. Janko Giuseppe Luigi Punzi wrote: > Looks interesting. > > Congratulations. > > Michael Perscheid escribió: >> Hi list, >> >> I am very proud to announce "SqueakSVN". >> >> SqueakSVN is our last bachelor project and joins Squeak with version >> control offered by Subversion. Squeak developers take advantage of >> team programming and the benefits of Subversion's growing popularity >> and support. >> >> More details can be found on our web pages. >> >> - Project Description: >> http://www.swa.hpi.uni-potsdam.de/projects/ssvn/index.html >> >> - Source Code Download: >> http://www.swa.hpi.uni-potsdam.de/projects/ssvn/media/SqueakSVN.sar >> >> - Demonstration Video: >> http://www.swa.hpi.uni-potsdam.de/projects/ssvn/media/ssvn_en.mp4 >> >> Best Regards, >> >> Michael Perscheid >> on behalf of the Software Architecture Group >> Hasso-Plattner-Institut, Potsdam >> > > > -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si |
Re: [squeak-dev] [ANN] SqueakSVN
|
|
Yesterday I watched Linus Torvalds talk on G IT at Google. Once you get past his obnoxious public persona there is meat here, and its well worth the 1 hour 10 minutes holding one's nose. I think he's right on distributed version control and so would like to see Monticello GIT integration. One of GIT's features that I think will be most synergistic with Smalltalk is that it is content addressable. That is, GIT can track the history of a function even if it moves from one file to another.
The system isn't a file tracker, it is a content tracker (in fact, a content addressible file system). This removes lots of issues in the mapping of Smalltalk methods to whatever the SCM system manages. In GIT there would be no problem mapping a class to a file. One could still track the history of a method within it with ease and GIT would still transmit only deltas, not the entire file, when a part of the method changed.
|
Re: [squeak-dev] [ANN] SqueakSVN
|
|
2008/9/16 Eliot Miranda <[hidden email]>:
> Yesterday I watched Linus Torvalds talk on G IT at Google. Once you get > past his obnoxious public persona there is meat here Look at the rate of change in Linux. A project this huge and critical changing so fast. And this with files, C and text editors. http://www.youtube.com/watch?v=L2SED6sewRw Cheers Philippe |
Re: [squeak-dev] Re: [ANN] SqueakSVN
|
|
In reply to this post by SergeStinckwich
Yes, a SVN repository which is accessed via http/WebDav can serve as a
Monticello repository. On Sep 15, 2008, at 6:29 AM, Serge Stinckwich wrote: > Michael Perscheid a écrit : >> Hi list, >> I am very proud to announce "SqueakSVN". >> SqueakSVN is our last bachelor project and joins Squeak with >> version control offered by Subversion. Squeak developers take >> advantage of team programming and the benefits of Subversion's >> growing popularity and support. > > > Nice ! > > Could you use a SVN repository as a monticello repository ? > > > -- > Serge Stinckwich > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://blog.doesnotunderstand.org/ > > |
Re: [squeak-dev] [ANN] SqueakSVN
|
|
In reply to this post by Eliot Miranda-2
On Tue, Sep 16, 2008 at 9:57 AM, Eliot Miranda <[hidden email]> wrote:
> Yesterday I watched Linus Torvalds talk on G IT at Google. Once you get > past his obnoxious public persona there is meat here, and its well worth the > 1 hour 10 minutes holding one's nose. I think he's right on distributed > version control and so would like to see Monticello GIT integration. One of > GIT's features that I think will be most synergistic with Smalltalk is that > it is content addressable. That is, GIT can track the history of a function > even if it moves from one file to another. > The system isn't a file tracker, it is a content tracker (in fact, a content > addressible file system). This removes lots of issues in the mapping of > Smalltalk methods to whatever the SCM system manages. In GIT there would be > no problem mapping a class to a file. One could still track the history of > a method within it with ease and GIT would still transmit only deltas, not > the entire file, when a part of the method changed. Yes, see my posts here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129602.html http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129605.html Git is modular enough that one could pretty easily, I think, replace its directory-of-files <=> content-tree mapping with a smalltalk-image <=> content-tree mapping and leave the majority of the system intact. Avi |
Re: [squeak-dev] [ANN] SqueakSVN
|
|
Hi Avi,
On Tue, Sep 16, 2008 at 11:55 AM, Avi Bryant <[hidden email]> wrote:
you state I personally believe that we're better off with Smalltalk-specific version control, but if someone *is* looking at integration with more mainstream tools, I would strongly suggest they start with git rather than SVN. Aviand I want to emphatically agree with you that we want integrated Smalltalk-specific version control. Lets say integrated Smaltalk-centric rathe rthan Smalltalk-specific because there is benefit in other tools & systems being able to access the source repository's contents without using Smalltalk (e.g. web serving, extracting documentation, bootstrapping and I'm sure much more). But none of this prevents using Git as a back-end. Git seems to have several key advantages (that I didn't mention at first; they're in the talk) that we can use. First, being distributed (based on divergent replicated repositories) there is no centralisation, no dependency on a server which, if it goes down, one can't work without. There is much higher performance because data is local (until one merges by pulling from other repositories). Second, there is protection against corruption (actually corruption detection) because contents are thoroughly check-summed. Most importantly content-addressability means mapping of Smalltalk to files is easier and not much of an issue.
But I'm not sure I buy the mapping of an image to the repository. I would rather browse packages than images (e.g. a packages subdirectory containing a directory per package) and I still want the changes file for crash recovery. But thats a tension right there. Does one keep Smalltalk structures like the changes file and their support or go the whole hog and just use Git for all source? Personally I want to keep as many of the tools in Smalltalk as possible so I can fix and extend them as I'm working. A large wadge of C should be kept in the back ground as much as possible. Its a file system after all.
Eliot
|
Re: [squeak-dev] [ANN] SqueakSVN
|
|
On Tue, Sep 16, 2008 at 4:40 PM, Eliot Miranda <[hidden email]> wrote:
> But I'm not sure I buy the mapping of an image to the repository. I would > rather browse packages than images (e.g. a packages subdirectory containing > a directory per package) and I still want the changes file for crash > recovery. Ah, agreed about browsing packages. I just meant, you can have Smalltalk code directly map a package from the image into a git repository, rather than having the intermediate step of spitting out a bunch of "source" files, which is what SqueakSVN does. > But thats a tension right there. Does one keep Smalltalk > structures like the changes file and their support or go the whole hog and > just use Git for all source? Personally I want to keep as many of the tools > in Smalltalk as possible so I can fix and extend them as I'm working. A > large wadge of C should be kept in the back ground as much as possible. Its > a file system after all. I think we're pretty used (from MC) to the duality of .changes and version control, and it works reasonably well - I wouldn't object to removing the changes file entirely but it seems like a lot of work to do so. As for keeping as many of the tools in Smalltalk as possible - well, there's a continuum there, from MC or MC2 where all the important bits are in Smalltalk, to SqueakSVN where most of the interesting stuff is hidden behind an API or external processes. What I envision with Git would be somewhere in between, where you would have Smalltalk code directly manipulating the Git data structures, but would still spend a lot of time using the command line git tools for stuff that didn't make sense to reimplement in Smalltalk. Avi |
Re: [squeak-dev] [ANN] SqueakSVN
|
|
In reply to this post by Eliot Miranda-2
On 17/09/2008, at 9:10 AM, Eliot Miranda wrote: > But I'm not sure I buy the mapping of an image to the repository. I > would rather browse packages than images (e.g. a packages > subdirectory containing a directory per package) and I still want > the changes file for crash recovery. But thats a tension right > there. Does one keep Smalltalk structures like the changes file and > their support or go the whole hog and just use Git for all source? > Personally I want to keep as many of the tools in Smalltalk as > possible so I can fix and extend them as I'm working. A large wadge > of C should be kept in the back ground as much as possible. Its a > file system after all. I've been working on GIT integration for some time, and I have a working system called MirrorImage that I have blogged about. It does use source files, although my thinking is that the fact that some ST artifact may be reified as a text stream is simply an API issue - text being a type, and the fact that it may be transfered on disk is equivalent to a parameter passing convention. I don't see what the big deal is here - as long as the domain mapping is bidirectional under all the transformations that GIT/Bazaar etc makes. When you compare VW and Squeak, one exemplar difference is in how overrides are handled. In VW they are up-front, which is a result of VW's emphasis on it's packaging system as a means of system construction and partitioning. IMO though, VW doesn't go far enough. MirrorImage reworks how classes are constructed from fragments, e.g. how different packaging units are combined to make up the definition of a class from attributes such as variables, traits and other properties, as well as methods. This includes not only incremental additive construction including ordered replacement/overrides, but subtractive and transformative construction. GST makes some steps in this direction by allowing you to incrementally add instance variables in extensions. The issue of system construction, at all levels of granularity, packaging, modularity, and version control, are IMO not orthogonal, and the greatest advance comes from considering them holistically. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 If you pick up a starving dog and make him prosperous, he will not bite you. This is the principal difference between a man and a dog. -- Mark Twain |
|
|
In reply to this post by Eliot Miranda-2
Git isnt the only game in town, there is also Mercurial and Bazaar.
Having tried both I prefer Bazaar. Its windows support is great. I version control my images using Bazaar. We could improve the image format to ensure that diffs work efficiently. I tried normalizing object pointers to a known base address as a starting point. However we could be cleverer I think. (One of the Bazaar devs is a squeaker) any thoughts? Keith |
[squeak-dev] Re: [ANN] SqueakSVN
|
|
Keith Hodges wrote:
> Git isnt the only game in town, there is also Mercurial and Bazaar. > Having tried both I prefer Bazaar. Its windows support is great. > > I version control my images using Bazaar. We could improve the image > format to ensure that diffs work efficiently. I tried normalizing object > pointers to a known base address as a starting point. However we could > be cleverer I think. (One of the Bazaar devs is a squeaker) Changing the base address might make loading slower. Git has filters that allow one to perform bidirectional transforms between the data that is on disk and the data that is in the working tree. People have used to store openoffice files uncompressed, so that diff works on them too. Do Mercurial and Bazaar have anything like that? Paolo (who uses git for GNU Smalltalk) |
[squeak-dev] Image normalization (was: SqueakSVN)
|
|
Am 17.09.2008 um 07:47 schrieb Paolo Bonzini: > Keith Hodges wrote: >> I tried normalizing object >> pointers to a known base address as a starting point. > Changing the base address might make loading slower. Actually, it makes it faster. If you mmap the image to a base address that is likely to be available the next time around, then you avoid the oop relocation on startup which touches the whole object memory. Thus image startup becomes blindingly fast since the pages do not even have to be loaded from disk until used. (You also have to disable the nonsensical check for finalization support, every VM made in the last 5 years supports it, and it's forcing a full GC on startup.) - Bert - |
[squeak-dev] Re: Image normalization
|
|
Bert Freudenberg wrote:
> > Am 17.09.2008 um 07:47 schrieb Paolo Bonzini: > >> Keith Hodges wrote: >>> I tried normalizing object >>> pointers to a known base address as a starting point. >> Changing the base address might make loading slower. > > Actually, it makes it faster. Yes, but that address might vary between systems. I interpreted Keith's sentence as "normalizing the base address to zero", not to something that is likely to be available the next time around. If the VM saves the objects with the current base address, it would probably choose an address that is likely to be available the next time around, but it might be different from what is under version control. Anyway, with direct object access (no OOP table) there is a fundamental problem that makes diff encoding of images almost impossible. If an object dies, everything after it is compacted and changes its address. If you have an OOP table, the objects are referenced through something that is never compacted, but if objects are accessed directly then every pointer in the image is changing. Paolo |
Re: [squeak-dev] Re: Image normalization
|
|
Am 17.09.2008 um 17:10 schrieb Paolo Bonzini: > Bert Freudenberg wrote: >> >> Am 17.09.2008 um 07:47 schrieb Paolo Bonzini: >> >>> Keith Hodges wrote: >>>> I tried normalizing object >>>> pointers to a known base address as a starting point. >>> Changing the base address might make loading slower. >> >> Actually, it makes it faster. > > Yes, but that address might vary between systems. I interpreted > Keith's > sentence as "normalizing the base address to zero", not to something > that is likely to be available the next time around. You can give a desired address to mmap(). We might find one that is likely to work on all systems. > If the VM saves the objects with the current base address, it would > probably choose an address that is likely to be available the next > time > around, but it might be different from what is under version control. > > Anyway, with direct object access (no OOP table) there is a > fundamental > problem that makes diff encoding of images almost impossible. If an > object dies, everything after it is compacted and changes its address. > If you have an OOP table, the objects are referenced through something > that is never compacted, but if objects are accessed directly then > every > pointer in the image is changing. As long as the garbage collector does not change the order of objects, the vast majority of oops in a saved image will not change even in a direct-pointer model with a fixed base address. Also, I've been thinking about freezing the lower part of the object memory to speed up gc - it makes no sense to always trace from the very beginning when most of the objects there are never modified (classes etc.). Something like perm space in VW ... - Bert - |
Re: [squeak-dev] Re: Image normalization
|
|
On Wed, Sep 17, 2008 at 8:24 AM, Bert Freudenberg <[hidden email]> wrote:
You know that's not how the GC works in incremental (high frequency) mode, right? The GC starts from young space using the rootTable as roots. Further, when the GC does a full GC it does a full trace (necessary) but only compacts from the lowest free. You could easily simulate perm space simply by adding a new generation, e.g. middleAgedStart. But the store check would be 1 comparison against a global more expensive (i.e. nearly twice as expensive, at least in code size).
|
Re: [squeak-dev] Re: Image normalization
|
|
Am 17.09.2008 um 19:37 schrieb Eliot Miranda: > You know that's not how the GC works in incremental (high frequency) > mode, right? The GC starts from young space using the rootTable as > roots. Yes I know. > Further, when the GC does a full GC it does a full trace (necessary) > but only compacts from the lowest free. You could easily simulate > perm space simply by adding a new generation, e.g. middleAgedStart. Perhaps, though I'm not sure about the "easily" part ;) The problem with a full GC is the mark bits, which are stored with the object so every last page in memory is marked dirty even for objects not modified (wouldn't you wish for an object table?) > But the store check would be 1 comparison against a global more > expensive (i.e. nearly twice as expensive, at least in code size). Unless someone has a brilliant idea, yes :/ - Bert - |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |