On 01/02/2012 09:13, Erik Sundvall wrote:
> Hi!
>
> On Wed, Jan 11, 2012 at 12:10, Ian McNicoll<
> Ian.McNicoll at oceaninformatics.com> wrote:
>
>> 1. Add some sort of persistence/ repository back-end for archetypes
>> and associated documentation e.g Github and/ or Dropbox. There is a
>> very nice Python API for the latter which I got working. This does not
>> need to be be particularly complex. Github would probably be a better
>> solution but the limited versioning afforded by Dropbox is probably
>> sufficient.
>>
>
> One of the most interesting things about GIT-like systems is their
> distributed/decentralized nature where there is not necessarily a single
> main master repository. (This category of versioning systems are often
> called DVCS, see
> http://en.wikipedia.org/wiki/Distributed_Version_Control_System, GIT is
> just an example from that category
> Mercurial<http://en.wikipedia.org/wiki/Mercurial>is another example.)
> Instead of centralization there is very good support
> for merging multiple branches/forks/origins. I think this mode of operation
> will suit future archetype development where we might expect considerable
> activity in many regional archetyping centres and then multi-source merges
> and good multi-branch change tracking will be useful.
>
> The git command-line interface itself would be quite a horrible experience
> to most archetype authors though so the DVCS needs to be wrapped in
> something better (CKM-like) for end users. Something like GIT (or
> Mercurial) itself might work well as a service layer for communication
> between regional archetyping repositories though, we probably won't need to
> add much there except some sensible rules for directory structures, file
> naming etc. Communication protocols etc for GIT are already defined - exposing
> the repository via a regular
> webserver<http://book.git-scm.com/4_setting_up_a_public_repository.html>
> directory
> is one option. Every regional site will via GIT or Mercurial automatically
> get a complete history of any other repository it wishes to mirror.
Yes Erik,
and GIT does it's best (unlike SVN) to help you merge even after a lot
of branching: see: http://progit.org/book/ch3-2.html for a nice explanation
