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

[Angel Java Lopez]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20121231/3670f750/attachment-0002.html>