[Cuis] Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

H. Hirzel hannes.hirzel at gmail.com
Mon Dec 31 05:05:47 CST 2012 

Hello Angel

thank you for this concise summary. It helps me a lot.

So a workflow for me could look like this

1) I work in my fork https://github.com/hhzl/Cuis
2) I create a branch for an  idea, fix, bug solution as concerns the
general Cuis development as well as branches for my own development.
3a) I issue pull requests to Juan for a particular branch if I think
it should go into Juan's repository.
3b) Juan accepts and merges the update or not.
3c) I re-synchronize with Juan's master branch from time to time by
     git pull upstream master  [1]
3d) I merge it into my master branch.
4) For the 'repositories' subdirectory: we have a branch for each
package group, i.e. one for PetitParser, one for RegularExpressions
etc.


>From a Cuis point of view it seems that this is a good solution.

So far however people have been developing external packages for Cuis
in separate repositories
https://github.com/jvuletich/Cuis/blob/master/ListOfCuisPackages.md.
In case of a package which should be loadable in different Squeak
(Smalltalk) distributions that seems to be better.

But as all packages on the list
https://github.com/jvuletich/Cuis/blob/master/ListOfCuisPackages.md
are Cuis specific they might as well just be maintained in individual
forks/branches of the main Cuis distribution as shown in
https://github.com/hhzl/Cuis  (no branches yet)

And in particular as it is about Smalltalk artifacts which are
compatible with the Cuis core.

What do you think?

--Hannes


[1] http://stackoverflow.com/questions/2257196/git-pull-from-other-branch

On 12/31/12, Angel Java Lopez <ajlopez2000 at gmail.com> wrote:
> Hi people!
>
> I don't know enough of Smalltalk (and its source code in file) to see the
> best o better way of using GitHub. But I see in other technologies, used in
> this way:
>
> - Branch x is an experimental branch, on new or improved feature a. For
> example, x == stm and the feature is a == Software Transactional Memory.
> Eventually, the branch dissapears, or it is merged with the main one
>
> - Branch x is for other platform. Some people uses branch in this way, or
> eventually it fork another project. But this way of use is rare, AFAIK
>
> - Branch x is an experimental branch, but born from an external pull
> request. That is, some other author wrote a Software Transactional Memory
> implementation, and then, the main author(s) of the central repo, accept
> his/her contribution, but not in master yet, only to be testes and stressed
> by all.
>
> In forked repos, branches are used by the external contributor in the
> following way. He/she has many ideas, fixes, issues it can resolved. Then,
> forks the original repo, and not start to work DIRECTLY on this new fork.
> Instead, he/she creates a branch FOR EACH idea, fix, bug solution, etc...
> The branches are used like the patches in other systems. Author makes a
> pull request to central repo, per branch. So, the central authors can
> accept or reject by branch.
>
> Regarding Juan question, about "elaborate", the above was about branch.
> About tags, you can see in the Smalltalk GNU project the use of tags for
> versions. That is the "standard" way on most technologies.
>
> Angel "Java" Lopez
> @ajlopez
> github:ajlopez
>
>
> On Mon, Dec 31, 2012 at 5:49 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>
>> I have now done a sample how a repository could look like, see
>> https://github.com/hhzl/Cuis
>>
>> A copy of PetitParser is in a subdirectory 'packages'.
>>
>> I did this following the instructions of Angel in the 'Learning github
>> ...' thread. Thank you, Angel.
>>
>> What is still missing is the proper use of branches. This should not
>> be done in a main branch but in a 'PetitParser' branch.
>>
>> --Hannes
>>
>> On 12/31/12, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> > Sorry, the last two mails should have gone under the 'Learning git'
>> > subject line.
>> >
>> > As for building a Cuis distribution from *.pck files I think we need a
>> > 'packages' and a 'scripts' directory in the main repository
>> >
>> > https://github.com/jvuletich/Cuis
>> >
>> > And as we are at adding directories...
>> >    in addition a 'documentation' directory
>> >
>> > --Hannes
>> >
>> > On 12/31/12, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> >> and later
>> >>
>> >> <citation>
>> >> Because a branch in Git is in actuality a simple file that contains
>> >> the 40 character SHA-1 checksum of the commit it points to, branches
>> >> are cheap to create and destroy. Creating a new branch is as quick and
>> >> simple as writing 41 bytes to a file (40 characters and a newline).
>> >>
>> >> This is in sharp contrast to the way most VCS tools branch, which
>> >> involves copying all of the project’s files into a second directory.
>> >> This can take several seconds or even minutes, depending on the size
>> >> of the project, whereas in Git the process is always instantaneous.
>> >> Also, because we’re recording the parents when we commit, finding a
>> >> proper merge base for merging is automatically done for us and is
>> >> generally very easy to do. These features help encourage developers to
>> >> create and use branches often.
>> >> </citation>
>> >>
>> >> Angel,
>> >>
>> >> how do you think we should use branches?
>> >>
>> >> Amber https://github.com/NicolasPetton/amber (Smalltalk which compiles
>> >> to JavaScript and runs on node.js or in a browser) for example only
>> >> has 5.
>> >>
>> >>
>> >> --Hannes
>> >>
>> >> On 12/31/12, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> >>> There are about 40 branches with names like 'Seaside', 'Omnibrowser',
>> >>> 'Filesystem' ....
>> >>>
>> >>> and the tags are used for version numbers.
>> >>>
>> >>> It seems that the integration/development of a subsystem is done in a
>> >>> branch.
>> >>>
>> >>> I think we all have to read Chapter 3 of the git book
>> >>>
>> >>> http://git-scm.com/book/en/Git-Branching
>> >>>
>> >>> <citation>
>> >>> Some people refer to the branching model in Git as its “killer
>> >>> feature” , and it certainly sets Git apart in the VCS community. Why
>> >>> is it so special? The way Git branches is incredibly lightweight,
>> >>> making branching operations nearly instantaneous and switching back
>> >>> and forth between branches generally just as fast. Unlike many other
>> >>> VCSs, Git encourages a workflow that branches and merges often, even
>> >>> multiple times in a day. Understanding and mastering this feature
>> >>> gives you a powerful and unique tool and can literally change the way
>> >>> that you develop.
>> >>> </citation>
>> >>>
>> >>> :-)
>> >>>
>> >>> --Hannes
>> >>>
>> >>>
>> >>> On 12/31/12, Juan Vuletich <juan at jvuletich.org> wrote:
>> >>>> Can you elaborate? You see here something I don't get.
>> >>>>
>> >>>> Thanks,
>> >>>> Juan Vuletich
>> >>>>
>> >>>> Angel Java Lopez wrote:
>> >>>>> Interesting... see the combination of tags and branches
>> >>>>>
>> >>>>> On Sun, Dec 30, 2012 at 6:53 PM, H. Hirzel <hannes.hirzel at gmail.com
>> >>>>> <mailto:hannes.hirzel at gmail.com>> wrote:
>> >>>>>
>> >>>>>     And I think it is useful to have a look at the directory
>> structure
>> >>>>> of
>> >>>>>        https://github.com/bonzini/smalltalk (GNU Smalltalk)
>> >>>>>
>> >>>>>     --Hannes
>> >>>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Cuis mailing list
>> >>>> Cuis at jvuletich.org
>> >>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>> >>>>
>> >>>
>> >>
>> >
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>

More information about the Cuis mailing list