After giving monticello a quick test drive, it does seem like VersionNumber would be a nice fit. It would allow you to have the option of branching the development of a package. Right now it seems that monticello forces you into reconciling differences. It would also fit nicely into your repository file naming conventions.
It was nice to see that when I had 2 images connected to the same repository and I tried to commit 2 different versions of the same package that Monticello detected that situation (when I committed in the second image) and forced me to update before it would allow me to commit changes. Then, when updating, it showed me the differences in the versions of the packages.
It would be great to use VersionNumber to allow branching, but still give a warning message and confirm whether or not the user would like to a) update from the repository (as Monticello does now and avoid a branch) or b) commit a branch version of the package. In my experience there is a real need for branching support. It typically happens following a major release where you need to issue minor updates while simultaneously moving the product forward for the next major feature release.
- Stephen
On Wed, 20 Nov 2002, Stephen Pair wrote:
It would be great to use VersionNumber to allow branching, but still give a warning message and confirm whether or not the user would like to a) update from the repository (as Monticello does now and avoid a branch) or b) commit a branch version of the package. In my experience there is a real need for branching support. It typically happens following a major release where you need to issue minor updates while simultaneously moving the product forward for the next major feature release.
Yes, branching is needed. What you're describing there is more or less how CVS does things - always merge on the client side, and explicitly branch the working copy when needed. The other model I'm considering is how I'm told StORE does things - every commit is effectively a branch, and you can ask the server to merge any two whenever you want. With that model, there's no merging on the client side - any update is effectively a checkout.
Stephen, a question about VersionNumber - can you build a coherent VersionHistory from a set of VersionNumbers, or is there some additional state that needs to be kept? Just wondering if I'd need to serialize a VersionHistory instance for each repository.
As for lighterweight protocols than XML-RPC - well, XML-RPC is pretty darn lightweight, but since you'll notice that there's only a small and well separated bit of code that deals with the remote repository access, feel free to send me an alternate implementation. I'd be happy to lose some dependencies.
Avi
Avi Bryant avi@beta4.com said:
Yes, branching is needed. What you're describing there is more or less how CVS does things - always merge on the client side, and explicitly branch the working copy when needed. The other model I'm considering is how I'm told StORE does things - every commit is effectively a branch, and you can ask the server to merge any two whenever you want. With that model, there's no merging on the client side - any update is effectively a checkout.
A problem with StORE is that you can branch without knowing (if you don't look really careful at the proposed version numbers), this happens a lot with multiple developers. When one finds out, some checkins later, you are faced with a merge over quite a number of versions which StORE ain't very good at (that's a problem with the StORE model, where the remote, central part is just a SQL database and you therefore need to fetch all the stuff to your image in order to merge - that gets slow quickly).
I'd rather have the option to choose on check-in. Even then, a commit-on-a-branch first with a subsequent merge would be fine. I do like the philosophy of StORE that 'the trunk' is whatever branch you care to designate as 'the trunk' and be liberal about branching. Branching in CVS is too hard.
As for lighterweight protocols than XML-RPC - well, XML-RPC is pretty darn lightweight, but since you'll notice that there's only a small and well separated bit of code that deals with the remote repository access, feel free to send me an alternate implementation. I'd be happy to lose some dependencies.
SRP?
On 21 Nov 2002, Cees de Groot wrote:
I'd rather have the option to choose on check-in. Even then, a commit-on-a-branch first with a subsequent merge would be fine. I do like the philosophy of StORE that 'the trunk' is whatever branch you care to designate as 'the trunk' and be liberal about branching. Branching in CVS is too hard.
Would it be too strange to allow both clientside and serverside merges?
As for lighterweight protocols than XML-RPC - well, XML-RPC is pretty darn lightweight, but since you'll notice that there's only a small and well separated bit of code that deals with the remote repository access, feel free to send me an alternate implementation. I'd be happy to lose some dependencies.
SRP?
Hey, I'm just using ReferenceStream to send the actual data over the wire. All XML-RPC is doing is marshalling and dispatching the method names, and dealing with version numbers. SRP doesn't do anything in that area, right?
Avy wrote:
Would it be too strange to allow both clientside and serverside merges?
No, but you're not thinking about it right. Forget client side vs server side for a moment...what you are merging are two branches in your semantic model...whether it happens on the client or server makes no difference except as it relates to performance and complexity of the communications protocol (and maybe security, but completely forget that issue for now). The question is, do I want to move all of my code objects to the client to perform the merge or not. If your clients are all working from a shared directory (with no server squeak process) then clearly, the only place you can do a merge is on the client.
- Stephen
I wrote:
Avy wrote:
Would it be too strange to allow both clientside and serverside merges?
No, but you're not thinking about it right. Forget client side vs server side for a moment...what you are merging are two branches in your semantic model...whether it happens on the client or server makes no difference except as it relates to performance and complexity of the communications protocol (and maybe security, but completely forget that issue for now). The question is, do I want to move all of my code objects to the client to perform the merge or not. If your clients are all working from a shared directory (with no server squeak process) then clearly, the only place you can do a merge is on the client.
- Stephen
Just a follow up to this...if you design the merge operation (in whatever form that takes) to work on your semantic model, then it should make no difference to you whether you are merging two package versions stored in the repository, or you are merging one package version stored in the repository and one that is only in the client image and has never made it into the repository (the case when you are wanting to avoid creating a branch in the repository).
- Stephen
On Thu, 21 Nov 2002, Stephen Pair wrote:
No, but you're not thinking about it right. Forget client side vs server side for a moment...what you are merging are two branches in your semantic model...whether it happens on the client or server makes no difference except as it relates to performance and complexity of the communications protocol (and maybe security, but completely forget that issue for now). The question is, do I want to move all of my code objects to the client to perform the merge or not. If your clients are all working from a shared directory (with no server squeak process) then clearly, the only place you can do a merge is on the client.
- Stephen
Just a follow up to this...if you design the merge operation (in whatever form that takes) to work on your semantic model, then it should make no difference to you whether you are merging two package versions stored in the repository, or you are merging one package version stored in the repository and one that is only in the client image and has never made it into the repository (the case when you are wanting to avoid creating a branch in the repository).
That is indeed how the merge operation is designed. In general, the semantic model is written to leave a lot of flexibility in terms of the process (when and how merges happen, etc). It's because that flexibility is there that I'm even bothering to ask how things should work ;) - any of these should be very simple to implement.
"Client side" vs. "server side" is maybe the wrong terms for what I'm asking - basically it comes down to whether you merge two numbered, committed versions (like StORE) or merge one committed version into your uncommitted working copy (like CVS). Or both. Does that make sense?
Avi Bryant avi@beta4.com wrote:
On Thu, 21 Nov 2002, Stephen Pair wrote:
No, but you're not thinking about it right. Forget client side vs server side for a moment...what you are merging are two branches in your semantic model...whether it happens on the client or server makes no difference except as it relates to performance and complexity of the communications protocol (and maybe security, but completely forget that issue for now). The question is, do I want to move all of my code objects to the client to perform the merge or not. If your clients are all working from a shared directory (with no server squeak process) then clearly, the only place you can do a merge is on the client.
- Stephen
Just a follow up to this...if you design the merge operation (in whatever form that takes) to work on your semantic model, then it should make no difference to you whether you are merging two package versions stored in the repository, or you are merging one package version stored in the repository and one that is only in the client image and has never made it into the repository (the case when you are wanting to avoid creating a branch in the repository).
That is indeed how the merge operation is designed. In general, the semantic model is written to leave a lot of flexibility in terms of the process (when and how merges happen, etc). It's because that flexibility is there that I'm even bothering to ask how things should work ;) - any of these should be very simple to implement.
"Client side" vs. "server side" is maybe the wrong terms for what I'm asking - basically it comes down to whether you merge two numbered, committed versions (like StORE) or merge one committed version into your uncommitted working copy (like CVS). Or both. Does that make sense?
Personally (without having used StORE) I think one good point in favour of merging into your uncommitted wc is that you can then abandon it all if you find out during the merge that, hey - this sucks.
The other model seems to require me to commit something before I can do the merge and then if I get second thoughts I have committed something that I perhaps regret.
This is IMHO one of the nice things with the CVS model - all work is done in a WC and I don't commit anything until I am satisfied.
Just my two öre...
regards, Göran
On Fri, 22 Nov 2002 goran.hultgren@bluefish.se wrote:
This is IMHO one of the nice things with the CVS model - all work is done in a WC and I don't commit anything until I am satisfied.
The model I'm actually leaning towards is one allowing distributed repositories - so you can "commit" to a local (in memory, even) repos, without needing to change anything on the shared server. This has a lot of nice properties, including what Stephen was talking about with working on a disconnected laptop, etc.
Too tired to go into it in detail now, but I have a long Jabber log between Colin and I that I may try to turn into a write up of the proposed model for those that are interested.
Avi
Avi Bryant avi@beta4.com wrote:
On Fri, 22 Nov 2002 goran.hultgren@bluefish.se wrote:
This is IMHO one of the nice things with the CVS model - all work is done in a WC and I don't commit anything until I am satisfied.
The model I'm actually leaning towards is one allowing distributed repositories - so you can "commit" to a local (in memory, even) repos, without needing to change anything on the shared server. This has a lot of nice properties, including what Stephen was talking about with working on a disconnected laptop, etc.
Ok, this sounds nice. I think Arch has something similar. (http://www.gnu.org/directory/sysadmin/vc/arch.html)
And sure, that does change the picture. Good to hear you are on top of things! :-)
regards, Göran
Avi wrote:
The model I'm actually leaning towards is one allowing distributed repositories - so you can "commit" to a local (in memory, even) repos, without needing to change anything on the shared server. This has a lot of nice properties, including what Stephen was talking about with working on a disconnected laptop, etc.
Yes, please support an in memory only repository...this will play nice with the Chango VM.
- Stephen
On 21 Nov 2002 09:15:51 +0100, cg@cdegroot.com (Cees de Groot) wrote:
A problem with StORE is that you can branch without knowing (if you don't look really careful at the proposed version numbers), this happens a lot with multiple developers.
I don't think it would be a big deal to modify the publish code to pop a notifier window over the publish window if a branch is happening...
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Seeker (Micro Autonomous Underwater Vehicle) http://www.huv.com
I was considering moving the tiff plugin code into squeakmap. But I really need a wintel version to complete the packaging.
Did anyone create one? Somehow I think 95% of the machines are windows, but only 5% of the developers are windows (95% linux/bsd/mac/arm non-windows)
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Is anyone considering moving the followings into SqueakMap:
1/- ADPCMCodecPlugin 2/- AsynchFilePlugin 3/- B2DPlugin 4/- B3DAcceleratorPlugin 5/- BitBltPlugin 6/- BMPReadWriterPlugin 7/- BrowserPlugin 8/- ConsolePlugin 9/- DropPlugin 10/ DSAPrims 11/- FFTPlugin 12/- FilePlugin 13/- FloatArrayPlugin 14/- FontPlugin 15/- GeniePlugin 16/- IntegerPokerPlugin 17/- JoystickTabletPlugin 18/- JPEGReaderPlugin 19/- JPEGReadWriter2Plugin 20/- Klatt 21/- LargeIntegers 22/- Matrix2x3Plugin 23/- MatixPlugin 24/- MIDIPlugin 25/- MiscPrimitivePlugin 26/- Mpeg3Plugin 27/- SecurityPlugin 28/- SerialPlugin 29/- SocketPlugin 30/- SoundCodecPrims 31/- SoundGenerationPlugin 32/- SoundPlugin 33/- Squeak3D 34/- SqueakFFIPrims 35/- StarSqueakPlugin 36/- SurfacePlugin 37/- UIDPlugin 38/- ZipPlugin
Cheers,
PhiHo.
P.S: I think there are still about a couple dozen more, at the top of my head, just couldn't recall what they are ;-)
--- PhiHo Hoang phiho.hoang@rogers.com wrote:
Is anyone considering moving the followings into SqueakMap:
1/- ADPCMCodecPlugin 2/- AsynchFilePlugin 3/- B2DPlugin 4/- B3DAcceleratorPlugin 5/- BitBltPlugin 6/- BMPReadWriterPlugin 7/- BrowserPlugin 8/- ConsolePlugin 9/- DropPlugin 10/ DSAPrims 11/- FFTPlugin 12/- FilePlugin 13/- FloatArrayPlugin 14/- FontPlugin 15/- GeniePlugin 16/- IntegerPokerPlugin 17/- JoystickTabletPlugin 18/- JPEGReaderPlugin 19/- JPEGReadWriter2Plugin 20/- Klatt 21/- LargeIntegers 22/- Matrix2x3Plugin 23/- MatixPlugin 24/- MIDIPlugin 25/- MiscPrimitivePlugin 26/- Mpeg3Plugin 27/- SecurityPlugin 28/- SerialPlugin 29/- SocketPlugin 30/- SoundCodecPrims 31/- SoundGenerationPlugin 32/- SoundPlugin 33/- Squeak3D 34/- SqueakFFIPrims 35/- StarSqueakPlugin 36/- SurfacePlugin 37/- UIDPlugin 38/- ZipPlugin Cheers, PhiHo. P.S: I think there are still about a coupledozen more, at the top of my head, just couldn't recall what they are ;-)
Wasn't there an ODBC plugin as well ? We *need* that one for sure!
===== ------------------------- Benoit St-Jean bstjean@yahoo.com Yahoo! Messenger: bstjean http://cactus.swiki.net -------------------------
Hi,
Wasn't there an ODBC plugin as well ? We *need* that one for sure!
There are an ODBC support in SqueakMap and it don't need a plugin (it uses FFI to odbc32.dll).
http://minnow.cc.gatech.edu/squeak/2480 http://map2.squeakfoundation.org/sm/package/ba5582d8-4e50-417c-abd1- 07dcd5c4d7b2
=====
Benoit St-Jean bstjean@yahoo.com Yahoo! Messenger: bstjean http://cactus.swiki.net
Cheers,
Diego Gomez Deck
"PhiHo Hoang" phiho.hoang@rogers.com is claimed by the authorities to have written:
Is anyone considering moving the followings into SqueakMap:
All of those as well as all the Interpeter code and VMMaker stuff will move out of the image and into SM Real Soon Now(tm). Patience, grasshopper.
tim
"Tim Rowledge" tim@sumeru.stanford.edu scribed:
"PhiHo Hoang" phiho.hoang@rogers.com is claimed by the authorities to
have written:
Is anyone considering moving the followings into SqueakMap:
All of those as well as all the Interpeter code and VMMaker stuff will move out of the image and into SM Real Soon Now(tm).
Hooray, we will have InterpreterPlugin Real Soon Now(tm ;-)
tim
Cheers,
PhiHo.
Avi Bryant wrote:
Yes, branching is needed. What you're describing there is more or less how CVS does things - always merge on the client side, and explicitly branch the working copy when needed. The other model I'm considering is how I'm told StORE does things - every commit is effectively a branch, and you can ask the server to merge any two whenever you want. With that model, there's no merging on the client side - any update is effectively a checkout.
I probably have the Envy model in mind (which in this regard is very similar to StORE) since I've never used CVS or StORE to any great extent. I also built an Envy clone (the ObjectStudio team edition) which behaves almost identically to Envy. And, I've used quite a few commercial file based tools (ClearCase being the main one). What I like about the direction you've taken so far is that you've restricted the publishing/versioning to the package level and you're creating a semantic model of the sources. As far as the CVS model vs the StORE model, I don't think you need to chose between the two. What I was suggesting is that you give the user the change to "opt out" of introducing a branch when they are about to commit changes that would create a branch. If they choose to go ahead with a branch, then you should also allow them to come back at any time in the future and perform a merge (and you'll probably want some annotation that a merge happened since VersionNumber can't implicitly express that a merge took place). A nice three-way merge tool will be nice to add (which could be used when you're trying to avoid a branch (i.e. merge the code in my image with the latest in the repository) or when you're merging two existing branches). The 3-way tool would show you the deltas between each branch and their common base version (which VersionNumber can tell you). We had this in the ObjectStudio team edition and it made life a lot simpler (as compared with Envy). Merging went from being a complex time consuming operation to being trivial in even the most complex scenarios. Having a tool like that enables you to more clearly see the intention of the changes that were made in each branch (sort of like being able to see the forest despite the trees).
Stephen, a question about VersionNumber - can you build a coherent VersionHistory from a set of VersionNumbers, or is there some additional state that needs to be kept? Just wondering if I'd need to serialize a VersionHistory instance for each repository.
The intention from the start was to allow a VersionHistory to be created from a simple listing of VersionNumbers (which means you could assemble a VersionHistory from a set of file names that have VersionNumbers embedded in them). You may need to add method or two to VersionHistory though...you'll probably want a method to initialize a VersionHistory with a set of VersionNumbers and then validate. I have rules in VersionHistory about how versions are allowed to be added/removed (i.e. I don't allow a VersionNumber that is the basis of two branches to be removed because that version would be needed in a 3-way merge operation).
As for lighterweight protocols than XML-RPC - well, XML-RPC is pretty darn lightweight, but since you'll notice that there's only a small and well separated bit of code that deals with the remote repository access, feel free to send me an alternate implementation. I'd be happy to lose some dependencies.
After using a local repository, it seems that maybe XML-RPC might not be the bottle neck I thought it was (of course, I'm also running on my 4 year old 266mhz backup machine right now...so everything is sloooow).
- Stephen
squeak-dev@lists.squeakfoundation.org
-
Avi Bryant -
Benoit St-Jean -
cg＠cdegroot.com -
diegogomezdeck＠consultar.com -
goran.hultgren＠bluefish.se -
John M McIntosh -
Jon Hylands -
PhiHo Hoang -
Stephen Pair -
Tim Rowledge