Frequency of saving changes to Monticello?

Hi,

With Subversion the motto is "commit frequently". I commit after
nearly every change, no matter how small. What is the
motto/approach/style for committing to Monticello your changes to your
classes?

Regards,

Grant
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Hi!

"Grant Rettke" <[hidden email]> wrote:
> Hi,
>
> With Subversion the motto is "commit frequently". I commit after
> nearly every change, no matter how small. What is the
> motto/approach/style for committing to Monticello your changes to your
> classes?

I think this is a bit personal. Some people tend to commit in the same
frequency as when using CVS/Svn or similar - "per feature or fix" so to
speak. But since you can't selectively commit say a single class (as you
can in CVS/Svn and those) this doesn't really hold for my personal way
of working. In say CVS I can sit back and make 5 different commits on
different parts of my file tree.

Or in other words - if you are very sequential in your work (only doing
one fix or feature at a time) then it works (if you don't mind the time
it takes - a larger package takes a bit of time to snapshot). But I tend
to do lots of things intertwined and then it breaks for me - so I tend
to do commits more seldomly, more like checkpoints.

But when I do commit - say a few times per day - then I first use the
"changes" button to bring up a diff view and write a proper version
comment listing all things I have done - that list tend to end up
somewhere between 5 and 10 items.

The reason I can get away with this is the superb merging capabilities
in Monticello - merging snapshots from different people and branches is
very easy even if the snapshots contain several changes - so the
granularity is not that big a deal for me.

regards, Göran
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

In Squeak, the system logs ***every*** code you edit and compile. You  
can have a look at what you did by opening
the "recover last changes"

So normally you should never lose any code. Now it is a good practice  
to commit each time you broke and fix
your test. Usually I write tests (red), then make them green and  
commit. :)
But this is in the great days of hacking.

Stef

On 10 janv. 07, at 19:28, Grant Rettke wrote:

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Your workflow might look something like:
1. Create a category for your business logic.
2. Create a category for the tests for (step 1).
3. Create a business logic class.
4. Create a business logic test class.
5. Run the test, it fails, implement that functionality.
6. Save to Monticello.

On 1/10/07, stephane ducasse <[hidden email]> wrote: _______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

As often as you can stand it.  I'm working with some large packages  
that take about 3-4 minutes to snapshot, save, and upload to the  
server based repository.

Typically I only save "releases" to MC where a release is defined as  
everything works AFAICS.  I save images after every successful set of  
changes, and I save the image as new version when I'm going to try  
something I might not keep that is going to seriously destabilize the  
current project.

Occasionally I crash things - then I recover lost edits from the  
changes file.

YMMV.
-Todd Blanchard

On Jan 10, 2007, at 10:28 AM, Grant Rettke wrote:

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners