On 01/22/2011 12:37 AM, Stéphane Ducasse wrote:
I think that a stupid numbering like the one we have now is not so bad, you do
not want to force
the tools to read all the metadata inside the files.
I think that we have many more places where we should improve: UI, network
layer,
Ok so I have the impression that we could get rid of branching or use another
delimiter.
Would it be ok?
Lukas?
Dale?
Stef
On Jan 24, 2011, at 7:06 PM, Dale Henrichs wrote:
On 01/22/2011 12:37 AM, Stéphane Ducasse wrote:
I think that a stupid numbering like the one we have now is not so bad,
Ok so I have the impression that we could get rid of branching or use another
delimiter.
You cannot get rid of branching, this is a central part of version
control and extensively used in many large projects.
In Seaside we use the following pattern, also see the documentation at
However, that doesn't change that $. and $- cannot be part of the
PackageName or Author.
Just $., forget what I said about $-.
Lukas
--
Lukas Renggli
www.lukas-renggli.ch
Then an quick/easy fix is to filter out $. from the FullName prompt in
the image.
Cheers
El lun, 24-01-2011 a las 14:16 -0800, Lukas Renggli escribió:
However, that doesn't change that $. and $- cannot be part of the
PackageName or Author.
Just $., forget what I said about $-.
Lukas
Then an quick/easy fix is to filter out $. from the FullName prompt in
the image.
That was one of my first changes to Pharo 0.0001.
Lukas
--
Lukas Renggli
www.lukas-renggli.ch
Current Pharo accepts $. as part of the full name.
El lun, 24-01-2011 a las 14:22 -0800, Lukas Renggli escribió:
Then an quick/easy fix is to filter out $. from the FullName prompt in
the image.
That was one of my first changes to Pharo 0.0001.
Lukas
--
Miguel Cobá
Filtering doesn't help if the package was saved from a Squeak or
GemStone image or someone hand edited their package name ...
I know that a number of folks don't care about anyone that isn't using
the latest version of Pharo, but that is not the case for all developers.
Monticello could be a
On 24 January 2011 14:31, Miguel Cobá miguel.c...@gmail.com wrote:
Current Pharo accepts $. as part of the full name.
Then it is broken.
Lukas
El lun, 24-01-2011 a las 14:22 -0800, Lukas Renggli escribió:
Then an quick/easy fix is to filter out $. from the FullName prompt in
the image.
What about branch from a branch ? In general you need a tuple of (base version,
branch id, branch version) to identify a branch version. Similarly a branch on
a branch would become ((base version, branch id, branch version), branch2 id,
branch2 version).
In VW we use the following convention
In VW we use the following convention
base version + branch id - branch version
which then naturally extends to
base version + branch id - branch version + branch2 id - branch2
version
Multiple branches are specified as given in the grammar. { . Branch
} in EBNF means zero
I think that a stupid numbering like the one we have now is not so bad, you do
not want to force
the tools to read all the metadata inside the files.
I think that we have many more places where we should improve: UI, network
layer, Filesystem.
So with a simple fix in the tools to follow a
On 20 January 2011 22:52, Lukas Renggli reng...@gmail.com wrote:
Following the coventions your name is 'Igor' and the package is on the
branch 'Stasenko'. Gofer proritizes the main branch.
how about retrieving the latest version regardless of branch?
Can you provide an example how to tell
Hi Igor,
2011/1/21 Igor Stasenko siguc...@gmail.com:
On 20 January 2011 22:52, Lukas Renggli reng...@gmail.com wrote:
Following the coventions your name is 'Igor' and the package is on the
branch 'Stasenko'. Gofer proritizes the main branch.
how about retrieving the latest version regardless
On 21 January 2011 10:16, Hernán Morales Durand
hernan.mora...@gmail.com wrote:
Hi Igor,
2011/1/21 Igor Stasenko siguc...@gmail.com:
On 20 January 2011 22:52, Lukas Renggli reng...@gmail.com wrote:
Following the coventions your name is 'Igor' and the package is on the
branch 'Stasenko'.
Lukas wrote:
Looks good, but instead of duplicating the documentation I would
rather just return the class comment from the help method.
Feel free to do so. I just wanted to point you to the fact
that you can already use the pier style notation to document
stuff.
Hope we will now see more docu
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com';
project: 'VMMaker';
install: 'CMakeVMMaker'
works well for me and loads correct *latest* version.
That isn't a
On 01/21/2011 08:11 AM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com';
project: 'VMMaker';
install: 'CMakeVMMaker'
works well for me and loads
On 21 January 2011 18:48, Dale Henrichs dhenr...@vmware.com wrote:
On 01/21/2011 08:11 AM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com';
project:
+1
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com';
project: 'VMMaker';
install: 'CMakeVMMaker'
works well for me and loads correct *latest* version.
That isn't a solution and open again a gratuitous discussion about gofer
So what is the convention because I would like to enforce it.
There is no need to have more mess.
Stef
On Jan 21, 2011, at 6:48 PM, Dale Henrichs wrote:
On 01/21/2011 08:11 AM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use
This thing of the initial is really upsetting.
I know that is old history and that even tools were made (monticello)
relying on them (even without specifying an accepted format, creating
more confusion) but I think that enough is enough.
So, monticello hasn't a format for the filenames of the
On 21 January 2011 20:41, Stéphane Ducasse stephane.duca...@inria.fr wrote:
So what is the convention because I would like to enforce it.
There is no need to have more mess.
i prefer to have
{PackageName}[-{subname}]*-(.*)\.{number}\.mcz
where in (.*) could be anything and we don't really
El vie, 21-01-2011 a las 13:55 -0600, Miguel Cobá escribió:
Yes we understand, but that only applies to centralized SCM like
subversion.
In a distributed SCM like git and monticello the number means nothing.
e.g. there could be two branches yours and mine, and both have 345
commits in it.
On 21 January 2011 20:48, Miguel Cobá miguel.c...@gmail.com wrote:
This thing of the initial is really upsetting.
I know that is old history and that even tools were made (monticello)
relying on them (even without specifying an accepted format, creating
more confusion) but I think that enough
On 21 January 2011 20:57, Miguel Cobá miguel.c...@gmail.com wrote:
El vie, 21-01-2011 a las 13:55 -0600, Miguel Cobá escribió:
Yes we understand, but that only applies to centralized SCM like
subversion.
In a distributed SCM like git and monticello the number means nothing.
e.g. there could
El vie, 21-01-2011 a las 21:00 +0100, Igor Stasenko escribió:
So lets do the same and get rid of numbers.
So, name will be
PackageName-SHA1.mcz
everything else, like author and commit date is in package
I am for this change, but as I pointed before, it would break things, or
more surely,
On 01/21/2011 08:11 AM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com';
project: 'VMMaker';
install: 'CMakeVMMaker'
works well for me and loads
El vie, 21-01-2011 a las 13:10 -0800, Dale Henrichs escribió:
On 01/21/2011 08:11 AM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com';
project:
On Jan 21, 2011, at 8:50 PM, Igor Stasenko wrote:
On 21 January 2011 20:41, Stéphane Ducasse stephane.duca...@inria.fr wrote:
So what is the convention because I would like to enforce it.
There is no need to have more mess.
i prefer to have
I can tell you more. I am specifically using this name, because:
when system asked me to enter initials, it wasn't warned me that my
name is wrong or refused to use it
and from that point, when something doesn't works because of my
initials, this is NOT my fault. This is a fault of those
On 01/21/2011 01:28 PM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 13:10 -0800, Dale Henrichs escribió:
Miguel,
A timestamp isn't sufficient in the presence of branching. How do other
SCMs identify branches?
I am not an expert, for sure :), but the way Git works AFAICT is by
storing in
Hello,
Gofer doesn't likes my package naming :(
When i use:
Gofer new
url: 'http://squeaksource.com/VMMaker';
package: 'CMakeVMMaker';
load.
it loads the CMakeVMMaker-EstebanLorenzano.15
however, if i open the MC repo browser, it clearly shows that most
recent version is
however, if i open the MC repo browser, it clearly shows that most
recent version is
CMakeVMMaker-Igor.Stasenko.16 (at the moment of writing this message)
Following the coventions your name is 'Igor' and the package is on the
branch 'Stasenko'. Gofer proritizes the main branch.
Gofer new
Hi Lukas,
maybe that class comment docu is not that obvious and it's time to
provide a help book.
With the new help extension in Pharo 1.2 (using a pragma as
you suggested) it is now also possible to write a book
completely independent from HelpSystem (Alains wikistyle help
based on pier).
Following the coventions your name is 'Igor' and the package is on the
branch 'Stasenko'. Gofer proritizes the main branch.
how about retrieving the latest version regardless of branch?
Can you provide an example how to tell Gofer to load it?
There is no such thing as the latest version in
Looks good, but instead of duplicating the documentation I would
rather just return the class comment from the help method.
Lukas
On 20 January 2011 13:09, Torsten Bergmann asta...@gmx.de wrote:
Hi Lukas,
maybe that class comment docu is not that obvious and it's time to
provide a help book.
37 matches
Mail list logo
