Squeak, source control, subversion, versioning, monticello, all that good stuff.
Locked
12
12
Re: Squeak, source control, subversion, versioning, monticello, all that good stuff.
 
|
On Jan 29, 2006, at 6:15 AM, Alexandre Bergel wrote: > Hi Collin! > >> On the other hand, we find it's pretty common to have more organic >> branching patterns in Monticello, > > What is an organic branching ? It's not a technical term, it's just a way of describing what "typically" happens with Monticello packages. You get lots of little micro branches that get merged back together pretty quickly. You don't see this in CVS because CVS forces you to merge before you commit if your changes are not based on the latest version in the repository. Simon had described a rigid branching pattern that requires fairly strict discipline by developers. This makes a lot of sense with CVS because CVS forces you to figure out the right ancestor for a three- way merge manually. That's why you do so much tagging in CVS; you're assigning names to the reversions you'll need to reference with a -j option in a later merge. With Monticello, you do need some kind of naming convention if you're going to have multiple branches in use by many developers all a the same time. That way you can easily tell what versions are on what branches. But it doesn't need to be as strict as with CVS, because Monticello will always be able to find the correct common ancestor for a merge. And if you find you based your work on the "wrong" version, you can always backport your changes to the place they need to be. So with Monticello, the branching discipline can be a little more relaxed. It's a means for helping developers understand how versions relate to each other, not for making sure merges work correctly. And that means that branches can grow a little more "naturally," or "organically." Colin |
Re: Squeak, source control, subversion, versioning, monticello, all that good stuff.
|
|
In reply to this post by Cees De Groot
Please excuse me for hacking and slashing your reply ;) We're all very polite around here, very refreshing!On 1/27/06, Simon Kirk [hidden email] wrote:Please excuse the verbosity.And please excuse me for snipping it all in my response :-). Wow, I certainly generated a big thread. Thanks very much for all the help and replies folks. :) I'm not sure what MCC is. Is it MC2? I have read in the list that the performance of MC2 is vastly improved over MC.The basic question is: can you do optimistic version control with MC with a larger group. Modulo some performance problems (which, it turns out, are related to source file writing and should be fairly simple to remove), I think with MC(+MCC) you have everything you need in the tools. I may have mislead somewhat with any emphasis on CVS, though - I'm talking more from the perspective of somebody who now uses svn - therefore I no longer need to worry about tagging (or special comments as you put it?) revisions in CVS, svn increments the revision number repository-wide on every commit, but I digress somewhat.You cannot (should not?) name versions, but I've used "special comments" in CVS with great success (I first used CVS when it was a bunch of shell scripts around RCS, so I'm reasonably experienced with the system), and with MC that shouldn't be any different. You have a good point about the extensibility of MC vs CVS, and it's indeed nice to know that the system in hand can be modded for our needs very well. However, in contrast to that it is my opinion a fully-fledged scm should already meet the requirements that I loosely specced out in my tome of an original email. Customisability is great, but with the merge tool seems to be a case in point: I think the merge functionality of Eclipse is a good model (well, certainly the best out of all the merge tools that I previously used) to start with, but how does MC compare? I can't categorically say as I haven't used MC enough (I'm using it now so I'm sure I'll hit the point to be able to compare soon), but the graphical "helpers" in Eclipse really make merging clear. I hope the merging in MC and Squeak measures up.The merge tool is simple but sufficient (and easy enough to extend - try to extend CVS while you're working with it ;-)) So I'll have to leave this here, for now: But I'll be happy to post my interpretations of MC/Squeak merging compared to Eclipse/Araxis Merge/diff/etc once I've got a bit more experience. , and branching support is very good. That's good to know, as branching is integral to my development model. I'm really thinking now that a large part of my worry with MC is that the documentation just doesn't cater well to people like me. I've read through the documentation on MC are wiresong.ca, and doesn't help much in the description of how MC works. There are no diagrams describing the branching model, or dependencies. A brief mention of the Merge button that Avi mentions in one of his replies to this thread. No mention of comparisons between svn/cvs/$YOURSCMHERE and MC. These things would all massively help the understanding of MC - and very importantly grease the wheels of transition between the more commonly-used programming languages and Squeak. Let's face it: the easier that transition is the better, because I think Squeak has such massive potential and every block that stops it being adopted is a Very Bad Thing (tm).Every MC version carries around its whole version history, so developers can commit versions to private repositories and then a final version to the shared repository; MC will see the gaps and just skip over them. I may have mislead a bit here as well - it was a single system, but it was about 50 seperate CVS (then svn) modules which were combined using J2EE/Tomcat/Eclipse cleverness into one coherant system :)[snip] Note, by the way, that I would object against any single system under development of a single 30-40 person team :-). I think the fact that it all worked smoothly was a testament to the development system we'd put together ;) Cheers, Simon This message has been scanned for viruses by BlackSpider MailControl |
Re: Squeak, source control, subversion, versioning, monticello, all that good stuff.
|
|
In reply to this post by Avi Bryant
Just to throw in my $0.02, there's only one mention of the Merge button in the MC documentation (that I've found anyway) under the section 'Getting Started', and that itself says just effectively "click merge" rather than describing what happens. It also (scarily imo) says it only merges non-conflicting changes, but doesn't mention how (if?) conflicts are dealt with. Perhaps that's why people perception of MC's merge support isn't great from the start? This isn't a comment on MC's *actual* merge capability, more its *perceived* capability :) S This message has been scanned for viruses by BlackSpider MailControl |
Re: Squeak, source control, subversion, versioning, monticello, all that good stuff.
|
|
In reply to this post by Colin Putney
Colin Putney wrote:
> > On Jan 27, 2006, at 11:23 AM, Simon Kirk wrote: > >> Now I find myself at the point of trying to justify Squeak for >> development here at my current job. I've got a lot of backing from >> "upstairs", but I want to know that if we use Squeak we can have the >> same level of granular control over source modification and control >> that I've had with Java in the past. To my current understanding >> Monticello just doesn't cut it - in fact (harsh as it may sound), >> the merging/diff tools in Squeak generally seem inferior to svn or >> even VAJ/ENVY. I seem to recall a post to this list that I read once >> from Avi saying that Monticello was more of a version delivery >> system than a source version control system - in other words that it >> was more useful as a way to deliver the upgrade of a version of a >> complete package at once, rather than people "checking code in an >> out" all the time as is more the case with cvs/ svn. Is this right? > > > Hi Simon, > > Perhaps a bit of history will give you the information you need to > make a sensible choice. A few years ago I was in a similar situation > to where you are now - moving from a file-based language managed by > CVS, to Squeak managed by... what? Avi was consulting for some > Seaside projects we were doing, and whipped up DVS as a way to let us > continue using CVS with Squeak. DVS evolved to the point where we > realized that CVS was holding us back rather than helping. So we > added native versioning capabilities and renamed it Monticello. > > It's interesting that you find the diff/merge capabilities of > Monticello to be lacking, because really that's the one thing > Monticello does really well. MC takes the same approach as CVS in > that it allows concurrent development, with the ability merge > parallel lines of development after they have diverged. In fact, > Monticello does a better job of it than CVS, because it handles > repeated merges without bogus conflicts. Also, it doesn't require you > to update before committing - if someone else has committed since > your checkout, you just end up creating a branched version that you > can merge back into the trunk later. Hi Colin. Thanks for your reply - as I've already said (but I'll repeat as it's well worth it), I really appreciate all the help everybody's been offering. A good advertisement for the community, I think.] As I've said elsewhere, I suspect it's the impression of MC's merge capabilities that is the problem, rather than its actual capabilities. The documentation on wiresong.ca is very thin on the ground about the branching model, and the merging capabilities of MC. To illustrate this I'll point out that I've learnt way more about MC by the spawning of this thread and the reading of the replies than I ever did by the documentation available, the mailing list archives, or even (I admit here that my useage has been woefully inadequate - indeed it must have been otherwise I wouldn't have been asking the questions I did :) using MC. As I've already written to Cees: "I've read through the documentation on MC are wiresong.ca, and doesn't help much in the description of how MC works. There are no diagrams describing the branching model, or dependencies. No mention of the 'merge' button that Avi mentions in one of his replies to this thread. No mention of comparisons between svn/cvs/$YOURSCMHERE and MC." There have been a lot of posts on this list over the years that I've seen discussing various gnarly points: documentation, acceptance of Squeak in the business world, etc. I think a very functional, well-documented and clearly illustrated SCM is key to the latter (as well as providing an easy way in for those of us who would like to contribute to the Squeak community as a whole, but aren't clear on the processes involved). MC is clearly already very functional, but the other points could do with a brush up. Of course, who's got time for that? ;) > > If you want to have a strict branching discipline with Monticello, it > wouldn't be hard. You could establish a convention for naming > versions to indicate the branch it's on. You'd set that name when you > save the first version on the new branch and Monticello would suggest > version names that preserve that convention. On the other hand, we > find it's pretty common to have more organic branching patterns in > Monticello, simply because merging is so easy. With CVS you need a > more structural discipline because it doesn't handle merges with > complicated histories correctly. Have a look at this entry from Avi's > blog for an example of what I mean: > > http://www.cincomsmalltalk.com/userblogs/avi/blogView? > showComments=true&entry=3291004466 > > All in all, I think Monticello would be a good fit to your needs. It > was written with exactly this sort of use in mind. Having seen that, and read other comments (and gone back over MC's documentation), I think you're dead right. Just to clarify: I'm much happier with organic branch growth, and the main reason for a strict branching discipline was due to CVS and the need to tag branches in order to have sanity about merging them. However I've been using svn for the last year, which removes that requirement by incrementing the build number of the whole repository upon each commit, forming a known point of branching whever anybody does so. Much nicer. The only other need for a strict branching discipline is maverick developers who have a habit of refactoring large swathes of shared library code in the main codebase that impact other people, live deployments, testing, etc. How would you suggest stopping people from being able to do this sort of thing? > >> * Here I'm talking about the auditing of changes against bug fixes: >> For instance with subversion I have a number of tools available: >> Fisheye from cenqua allows me to track who's checking what in where >> via RSS, and scmbug glues svn and bugzilla together such that >> comments of the form "bug 45: Some changes for this bug" will >> automatically put a comment into bugzilla against that bug: Getting >> developers to responsibily and happily use bug tracking software is >> quite a challenge! > > > Yeah, this kind of thing is important, but not covered my Monticello > per-se. Have a look at SqueakSource. It provides a web front end to a > Monticello repository, including RSS feeds with commit messages. I > don't know of anyone that has done bugzilla integration, but I > imagine it could be done. That's interesting, I shall have to take a closer look. So many things, so little time. Does MC have any kind of pre/post "commit" hooks that can be used for scripting of events into other systems? Sorry, this may be in the documentation here, but I'm writing about five replies on this thread, I'm getting lazy ;) > > Good luck with this, I hope you're able to use Squeak for your project. > > Colin > Thanks - I do, too, in a big way. S This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com |
Re: Squeak, source control, subversion, versioning, monticello, all that good stuff.
|
|
In reply to this post by Avi Bryant
Avi Bryant wrote:
> > On Jan 27, 2006, at 8:23 AM, Simon Kirk wrote: > >> Now I find myself at the point of trying to justify Squeak for >> development here at my current job. I've got a lot of backing from >> "upstairs", but I want to know that if we use Squeak we can have the >> same level of granular control over source modification and control >> that I've had with Java in the past. To my current understanding >> Monticello just doesn't cut it - in fact (harsh as it may sound), >> the merging/diff tools in Squeak generally seem inferior to svn or >> even VAJ/ENVY. I seem to recall a post to this list that I read once >> from Avi saying that Monticello was more of a version delivery >> system than a source version control system - in other words that it >> was more useful as a way to deliver the upgrade of a version of a >> complete package at once, rather than people "checking code in an >> out" all the time as is more the case with cvs/ svn. Is this right? > > > No, I don't think I would have said that - I certainly don't agree > with it :) What do you find weak about the merge and diff tools in > Monticello? I suspect it may be a matter of being poorly documented > (which they are) rather than technically inferior (I would, in fact, > claim the opposite). *blush*, I think I may have done a bit of a switcheroo there. Reading this, you actually said pretty much the exact opposite of what I mentioned before wrt version delivery vs source control. My apologies. I'm starting to be a bit redundant in my replies, sadly, but you appear to have hit the nail on the head without my having to spell it out: the documentation of the MC interface and capabilities is pretty unhelpful. I've already said to Cees (and referenced it to Colin - I won't repeat it again) about how important I think an SCM is the transition to Squeak. I think you've done the most important part well: Making something that *works properly*. But almost as important is making it easy to understand. Again, I've learnt a lot more about MC via this thread than I have by the MC documentation, or old posts to the mailing lists. Sure, I could learn a lot more if I actually used it properly, I fully admit that. But my time is probably like anybody elses: Very limited, and given that I'm the only person really using Squeak at the moment in my team, trying to understand MC's performance and process in a multi-developer environment is difficult without documentation and illustrated examples as there simply isn't anybody else working on my source tree :) Another point other than documentation is the "friendliness" of the GUI. Yes, it's very clean and simple, but it's not very inviting, or intuitive for the uninitiated. There were also some comments from Andreas and Stef mentioning their perceived weaknesses of the GUI. Is this something that's being adressed in MC2? > The one thing that's awkward to do in Monticello is to cherry pick a > small number of changes from one branch and apply them to a different > branch, rather than merging entire branches - in fact, Monticello > goes smoothest if you have the (sometimes unrealistic) discipline and > foresight to implement any change as an independent branch from the > earliest point in the ancestry at which it could have been made, to > maximize the potential places where you could merge it in. MC2 will > do this better, but even in MC1, the worst case is that you cherry > pick "manually" without the ancestry getting correctly recorded and > risk some spurious conflicts later on in face of a repeated merge. An interesting point here, as the process you're suggesting is pretty much the process that we had implemented at my previous job: That any change is made in an independant branch. Given that this is something that you have clearly thought about before; it would appear that Colin was right when he suggested that MC was in fact dead-right for my requirements. FWIW I think you're right that such a discipline is sometimes unrealistic: But that's ok, software development is always a tangential approach to an unattainable ideal reality. Ooh, that sounds pretentiously good. I think I should patent it for management training ;) >> >> Similarly, there was a system that Avi wrote a while back (I think >> this was pre-MC) called DVS. However the archive on squeak dev isn't >> clear on exactly what it was. From what I read it seemed much more a >> "snapshot all of the image and shove it straight into whatever scm >> we're pointing at" system, rather than dealing with individual >> files. I may however be doing it an enormous injustice here. > > Replace "all of the image" with "all of a package" and you've about > got it. I really wouldn't recommend going back to DVS. Don't worry I wasn't advocating that :) >> So having gone through all that preamble (and that hopefully >> whatever poor souls have made it this far now have a handle on the >> way I used to work) I can ask the simpler question: Using Squeak how >> would one go about developing a system in a safe, recordable and >> easy manner in a multi-developer environment, while maintaining >> linkage with a bug-tracking system such as bugzilla, in a way that >> is non-obtrusive* to the developer? > > Here's a possible set of practices: > - Start out by having a mainline/HEAD branch in Monticello, named > after the product. If your package is "Foo", version names might > look like Foo.2.0-avi.1, Foo.2.0-cwp.2, etc. > - When addressing an issue recorded in bugzilla, start by loading the > earliest mainline release in which the bug is evident or in which the > feature could be implemented. Make the fixes/changes, and then > commit and name the version after the issue, eg, Foo.bug45-avi.1. > This may be a single version, or it may turn into a branch (Foo.bug45- > avi.2, Foo.bug45-avi.3, etc). Automatically add the note to bugzilla > when you see the version name of that form. > - Periodically integrate these bug branches into the appropriate > product branches (load the latest version from the product branch, > select the latest version on the bug branch, press Merge, deal with > any conflicts, and then commit back the merged version as the next > version on the product branch with an appropriate note). > > Does that make sense? > > Avi Brilliant - that's exactly the kind of breakdown that I wanted. It seems embaressingly simple when laid out like that, but perhaps this is exactly the kind of thing that ought to also be in the MC domentation? I'll repeat the question I asked to Colin: Does MC have any kind of pre/post "commit" hooks that would facilitate the ability to automatically add bugzilla notes? Cheers, S This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com |
Re: Squeak, source control, subversion, versioning, monticello, all that good stuff.
|
|
In reply to this post by Bert Freudenberg-3
Bert Freudenberg wrote:
> Am 29.01.2006 um 08:41 schrieb Avi Bryant: > >> What do you find weak about the merge and diff tools in Monticello? > > > The automatic merging works very nicely for us. I even find myself > formatting methods so they produce a nice diff ;-) Like, we have a > method that lists the versions of packages used to build an image. > It's laid-out as one line per package, so in the diff each changed > package stands out visually :) > > However, *if* there are conflicts, tool support is lacking. Apart > from the wording in the merge-browser's interface, which I got used > to, I'd like to properly resolve conflicts right there while merging. > Currently it's either-or: you have to keep your method or replace it > with the incoming method. > > As a work-around, I usually accept all the incoming methods, but open > a method browser on each of them. After the merge I go to each one to > properly adjust the code manually, using the changes-based diff to > see what happened. > > It'd be very nice to be able to edit the new method right there in > the merge browser. Visually, a three-pane layout showing the old, the > new, and the merged hand-edited version would be very nice. But only > being able to edit the code in a single pane would be an improvement, > too. > > Fortunately, it happens not very often we actually have conflicts, > and even then, the majority can be resolved by using either the old > or the new version. But I guess the remaining cases are what people > mean when they ask for a better 3-way merge. > > - Bert - That's exactly the kind of thing I was thinking about in terms of merging - you put it very clearly, Bert. It may be that I don't understand the merge tools availble in Squeak properly, but when compared to those in Eclipse, Araxis Merge, whatever, they seem quite poor and under-featured, which is not the case judging from other comments here. S This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com |
RE: Squeak, source control, subversion, versioning, monticello, all that good stuff.
|
|
In reply to this post by Simon Kirk-4
> From: [...] Simon Kirk
> The only other need for a strict branching discipline is maverick > developers who have a habit of refactoring large swathes of shared > library code in the main codebase that impact other people, live > deployments, testing, etc. How would you suggest stopping people from > being able to do this sort of thing? First offence: Being beaten over the head ritually with the procedures manual, in which it is said that You Don't Do That. Second offence: Being transferred to an XP team, where such behaviour is tolerated. Third offence (if they manage to alienate the XP people): Dynamite. Or being assigned Wally (from Dilbert) as a pair programmer. More seriously... there's not really a technical way of preventing this. Human approaches are required, which can (should?) include removing the maverick from the project, and possibly the company. Seems harsh, but I've seen such a person wreck a project. - Peter |
Re: Squeak, source control, subversion, versioning, monticello, all that good stuff.
|
|
In reply to this post by Simon Kirk-4
On 1/30/06, Simon Kirk <[hidden email]> wrote:
> I'm not sure what MCC is. Is it MC2? I have read in the list that the > performance of MC2 is vastly improved over MC. > MCC is MonticelloConfigurations, a simple add-on package to store configurations of package versions, so you can load back a release whenever you need to patch against it. > Let's face it: the easier that transition is the better, because I think > Squeak has such massive potential and every block that stops it being > adopted is a Very Bad Thing (tm). > You're absolutely right. I think that we're making progress here, but the problem is that we're changing Squeak (in all its facets) so fast that it is extremely hard to keep up with documentation. For example (and this should help boosting your trust in Monticello), just two years ago (I think) everyone was still exchanging changesets etcetera. MC took the community by storm, and has changed how people work on every level (from publishing private packages via SqueakSource, another major enabler, to how 3.9a is developed). > I may have mislead a bit here as well - it was a single system, but it was > about 50 seperate CVS (then svn) modules which were combined using > J2EE/Tomcat/Eclipse cleverness into one coherant system :) > Sorry. I have to run for a bucket :P |
Re: Squeak, source control, subversion, versioning, monticello, all that good stuff.
|
|
That's all great - I'll be taking all the advice I've been given here and applying it, hopefully I'll be able to get everything as I would wish it - if not I'll whine again (ahem)On 1/30/06, Simon Kirk [hidden email] wrote: Haha :) It made sense.. honest? This message has been scanned for viruses by BlackSpider MailControl |
Re: Squeak, source control, subversion, versioning, monticello, all that good stuff.
|
|
In reply to this post by Peter Crowther-2
Heh! No, there's no actual person doing this (thankfully), just that everybody's guilty of it from time to time (even if by accident), so I was just curious. Being assigned Wally would be cruel and unusual punishment - but for a third offense most likely just. I do agree that if somebody does this regularly they can be a danger to a project. I think that's where being able to keep an eye on the changes going in via something like RSS is handy. S This message has been scanned for viruses by BlackSpider MailControl |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |