[Cuis] Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])
Juan Vuletich
juan at jvuletich.org
Mon Dec 31 14:47:58 CST 2012
Thanks Angel. Your insights will surely be very useful, even if we'll
take it slow.
Cheers,
Juan Vuletich
Angel Java Lopez 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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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>
> >>>>> <mailto: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 <mailto:Cuis at jvuletich.org>
> >>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >>>>
> >>>
> >>
> >
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org <mailto: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