« Return to Thread: ANN: Dojo on github
Re: ANN: Dojo on github
by John Locke
::
Rate this Message:
Great stuff.
> Of course we can tag a point in time, but branching introduces problems.
> Example: somebody working on the trunk modified a certain module, later
> on a problem was found and a fix was created, now the release manager
> wants the fix in the "1.3" branch but without new functionality. It
> means when we are ready to tag "1.3.2" we will tag the branch, not the
> trunk.
>
Do you mean that tags are getting treated as branches, with additional
commits after the tag? If so, then all the tags in my repo are suspect.
If you're just talking about the difficulty of managing a long running
1.2 branch in git, that's done in my approach, mirroring the entire svn
repo.
> Ideally I want to address both problems, yet continue to maintain
> separate repositories.
>
> Maybe it makes sense to create a super repository to unite all projects
> under one roof. Will Riley proposed to do it with submodules. Sounds
> simple, but as far as I remember with submodules you can refer to a
> particular commit in an external repository, but I want to track live
> (the latest). Any ideas about that are welcomed.
Well, I started out trying the submodule approach, but as you've found,
couldn't get it to work cleanly with tags and branches. I load Dojo as a
submodule in my own projects, and yes, what you get in the main project
is a commit id. When you update the submodule (using git submodule
update in the master project), it'll check out that particular commit,
without putting it on a branch.
I used a similar strategy, only instead of using a submodule for each
project, I used a branch for each project. And then I created a master
branch that used the "subtree" merge strategy to combine the trunks of
each project into the master branch. You can still check out the
individual projects directly--but you still have trouble getting a
tagged version of the project, or a branch.
I think the real problem here is the Subversion layout. It's a problem
even in subversion--there's no clean elegant way to switch between a
particular tag and trunk, if you want dojo, dijit, and dojox. This
really complicated my development process, especially when I had to
start backporting patches to a tagged release. The cleanup I did in git
really solved all these issues in our development.
The svn book recommends either having tags, trunk, and branches at the
top level of your repo, with individual projects as subdirectories; or
having projects at the top level of the repo, each with tags, trunk and
branches inside the project directory. Dojo's svn does both, making it
completely mixed up -- code for tags and branches are stored in a top
level tags and branches directory, with each project inside it, but
trunk code is all in top level individual project folders, with a trunk
directory inside it! That's the whole problem. Pick one or the other, or
else we're stuck with a Frankenstein monster of a git mirror, or a
really messed up development process too.
So my suggestion is, fix Subversion first! Then your (and my) git mirror
can get much simpler, and you'll make it easier for all the new users to
test trunk in the process.
Two real options for this:
1. Project oriented. In the svn repo, move tags/release-1.3.1/dojo (and
all of tags/*/dojo) to dojo/tags/release-1.3.1. Move branches/1.3/dojo
to dojo/branches/1.3. Now you have independent projects, each with
trunk, tags, and branches all under one path, easy to split
out/clone/whatever.
2. Release oriented. (my preference--I still see these projects as going
together). Move dojo/trunk to trunk/dojo, dijit/trunk to trunk/dijit,
etc. Now users can check out trunk and see all projects, with exactly
the same layout as checking out branches/1.3 or tags/release-1.3.1. This
makes it much easier to switch between trunk and a tag.
Either way makes mirroring in git much, much easier. The first lends
itself to submodules, and would make it easier for 3rd party projects
and things like plugd to get distributed alongside dojo. Sounds like the
direction the project is heading.
Cheers,
John Locke
http://freelock.com
-------- Original Message --------
Subject: Re: [Dojo-interest] ANN: Dojo on github
From: Eugene Lazutkin <eugene.lazutkin@...>
To: dojo-interest@...
Date: Thu 25 Jun 2009 02:29:22 PM PDT
> I didn't import branches and tags to avoid facing the non-standard SVN
> setup used by Dojo. ;-) I added some tags manually (0.9.0b-1.0.2), and
> still plan to experiment with branches and tags.
>
> Thank you for the link to your notes on the setup. I appreciate that you
> took time to write them --- clearly I don't want to reinvent the wheel.
>
> Incidentally I planned to blog on the mirror setup too, but now I will
> postpone it until I try to incorporate branches and tags.
>
> I have a git two-way mirror for Dojo for over a year now. But there are
> two sticky points I have noticed since mirroring to github:
>
> 1) Branches.
>
> For my work I don't need anything but trunk. For branches like "1.3" I
> just clone the branch in a new directory as a trunk and work separately
> with it.
>
> For the mirroring we decided to have separate repositories for Dojo,
> Dijit, DojoX, Util, and Demos. The underlying ideas were:
>
> a) Some people want just Dojo and nothing else, or Dojo + Dijit, or Dojo
> + DojoX + Util, and so on. For example you don't mirror Demos, and this
> should be totally fine --- there are many reasons to track projects
> separately. Having different repositories provides for that naturally.
>
> b) Some day we will want to separate release schedules of these
> projects. I suspect that we will have some synchronization points, like
> major releases, but minor releases like bug fixes can be produced on as
> needed basis by individual projects.
>
> 2) Tags.
>
> The existing Dojo SVN setup introduces a lot of complications because it
> uses a single server to track everything. For example, the release
> manager decided to tag a release, say, "1.3.2". It may fall on a
> changeset, which is not tracked by a particular repository or their
> combination.
>
> Of course we can tag a point in time, but branching introduces problems.
> Example: somebody working on the trunk modified a certain module, later
> on a problem was found and a fix was created, now the release manager
> wants the fix in the "1.3" branch but without new functionality. It
> means when we are ready to tag "1.3.2" we will tag the branch, not the
> trunk.
>
> Who cares about tags? github does. For every tag it creates a download
> completely automatically (see: http://github.com/dojo/dojo/downloads). I
> want it to be coherent and consistent.
>
> ===
>
> Ideally I want to address both problems, yet continue to maintain
> separate repositories.
>
> Maybe it makes sense to create a super repository to unite all projects
> under one roof. Will Riley proposed to do it with submodules. Sounds
> simple, but as far as I remember with submodules you can refer to a
> particular commit in an external repository, but I want to track live
> (the latest). Any ideas about that are welcomed.
>
> Thanks,
>
> Eugene Lazutkin
> Dojo Toolkit, Committer
> http://lazutkin.com/
>
>
> On 06/25/2009 03:30 PM, John Locke wrote:
>
>> Happy to see this! Good start guys.
>>
>> I do notice that the git repositories only mirror trunk, right? I'm not
>> seeing any tags or branches.
>>
>>
>> For an alternative approach (and many of you know about this already),
>> I'm also providing a git mirror of the dojo svn repository. I've done a
>> fair amount of wrangling to get the dojo, dijit, dojox, and util
>> repositories imported into a single branch on one repo, with the same
>> layout as you get in a tag or branch. This makes it very convenient to
>> switch between trunk and a specific tag.
>>
>> I'm going to write up and post a summary of our workflow on my blog
>> soon, based on an earlier thread about managing dojo builds. But
>> meanwhile you can clone my git repo at
>> git://git.freelock.com/git/dojo.git, and browse it at
>> http://git.freelock.com/?p=dojo.git;a=summary . Or you can replicate our
>> setup using my notes, http://freelock.com/kb/Git
>>
>> Our git mirror gets updated from svn automatically every 6 hours. Use
>> the "master" branch for trunk of all 4 projects (I haven't included the
>> demos trunk). Use dojo-trunk, dijit-trunk, dojox-trunk, and util-trunk
>> branches as equivalents of the "official" git release. You should be
>> able to format patches based on these branches to commit back to svn...
>>
>>
>> Cheers,
>> John Locke
>> http://freelock.com
>>
>> -------- Original Message --------
>> Subject: Re: [Dojo-interest] ANN: Dojo on github
>> From: Matthew Weier O'Phinney <matthew@...>
>> To: dojo-interest@...
>> Date: Tue 23 Jun 2009 08:36:19 AM PDT
>>
>>> -- Peter E Higgins <dante@...> wrote
>>> (on Tuesday, 23 June 2009, 11:24 AM -0400):
>>>
>>>
>>>> This concern was brought up at the last meeting. We made note explicitly
>>>> that any decision to change the VC core would be preceded by much
>>>> documentation and testing beforehand. There will be no surprises, and IF
>>>> it were to happen, we'd provide a crystal-clear migration guide.
>>>>
>>>> This GitHub thing, as Eugene points out, is experimental and
>>>> unidirectional at the moment. There simply was a tremendous amount of
>>>> interest in allowing folks to get Dojo from a git repository, as it is
>>>> an exceptionally popular DVC these days.
>>>>
>>>>
>>> Perfectly understandable, and something we're considering ourselves
>>> (lots of contributors are interested in using Git, and I myself
>>> personally mirror all the ZF repos locally as git repositories to
>>> facilitate experimental branching and offline commits).
>>>
>>> Thanks for the clarifications, everyone, and very excited to see another
>>> project using git!
>>>
>>>
>>>
>>>
>>>> Eugene Lazutkin wrote:
>>>>
>>>>
>>>>> No current plans to move the primary from SVN to any other SCM.
>>>>> Obviously the official mirror on github is the exploratory move, but any
>>>>> decision to move (if any) will be taken after we gather some experience
>>>>> with mirroring, and we will take into account opinions of all
>>>>> stakeholders and major users. Clearly Zend is included, and we don't
>>>>> plan to leave anybody hanging.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eugene Lazutkin
>>>>> Dojo Toolkit, Committer
>>>>> http://lazutkin.com/
>>>>>
>>>>> On 06/23/2009 07:00 AM, Matthew Weier O'Phinney wrote:
>>>>>
>>>>>
>>>>>
>>>>>> -- Eugene Lazutkin <eugene.lazutkin@...> wrote
>>>>>> (on Monday, 22 June 2009, 10:55 PM -0500):
>>>>>>
>>>>>>
>>>>>>
>>>>>>> As of now all five major Dojo repositories are available on github as
>>>>>>> official mirrors: http://github.com/dojo
>>>>>>>
>>>>>>> http://github.com/dojo/dojo/tree
>>>>>>> http://github.com/dojo/dijit/tree
>>>>>>> http://github.com/dojo/dojox/tree
>>>>>>> http://github.com/dojo/util/tree
>>>>>>> http://github.com/dojo/demos/tree
>>>>>>>
>>>>>>> All mirrors are read-only. No branches (save for master) are mirrored. I
>>>>>>> plan to add tags later.
>>>>>>>
>>>>>>> For now I will update mirrors manually 1-2 times a day. Later it will be
>>>>>>> automated, but in any case expect a lag --- our Subversion repository is
>>>>>>> still the primary.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Will Dojo be migrating entirely to Git at some point, or will github
>>>>>> simply be a mirror, allowing contributors to push via git+svn?
>>>>>>
>>>>>> I ask as a move to git would require some changes to Zend Framework
>>>>>> infrastruture, as we currently pull in Dojo via svn:externals. :)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> FAQ: http://dojotoolkit.org/support/faq
>>>>> Book: http://dojotoolkit.org/docs/book
>>>>> Forums: http://dojotoolkit.org/forum
>>>>> Dojo-interest@...
>>>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Peter E Higgins
>>>> Dojo Project Lead : http://dojotoolkit.org
>>>>
>>>> _______________________________________________
>>>> FAQ: http://dojotoolkit.org/support/faq
>>>> Book: http://dojotoolkit.org/docs/book
>>>> Forums: http://dojotoolkit.org/forum
>>>> Dojo-interest@...
>>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>>>>
>>>>
>>>>
>>>
>>>
>> _______________________________________________
>> FAQ: http://dojotoolkit.org/support/faq
>> Book: http://dojotoolkit.org/docs/book
>> Forums: http://dojotoolkit.org/forum
>> Dojo-interest@...
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>>
>>
>
> _______________________________________________
> FAQ: http://dojotoolkit.org/support/faq
> Book: http://dojotoolkit.org/docs/book
> Forums: http://dojotoolkit.org/forum
> Dojo-interest@...
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>
> !DSPAM:4a43ec6f248235057925723!
>
>
_______________________________________________
FAQ: http://dojotoolkit.org/support/faq
Book: http://dojotoolkit.org/docs/book
Forums: http://dojotoolkit.org/forum
Dojo-interest@...
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
> Of course we can tag a point in time, but branching introduces problems.
> Example: somebody working on the trunk modified a certain module, later
> on a problem was found and a fix was created, now the release manager
> wants the fix in the "1.3" branch but without new functionality. It
> means when we are ready to tag "1.3.2" we will tag the branch, not the
> trunk.
>
Do you mean that tags are getting treated as branches, with additional
commits after the tag? If so, then all the tags in my repo are suspect.
If you're just talking about the difficulty of managing a long running
1.2 branch in git, that's done in my approach, mirroring the entire svn
repo.
> Ideally I want to address both problems, yet continue to maintain
> separate repositories.
>
> Maybe it makes sense to create a super repository to unite all projects
> under one roof. Will Riley proposed to do it with submodules. Sounds
> simple, but as far as I remember with submodules you can refer to a
> particular commit in an external repository, but I want to track live
> (the latest). Any ideas about that are welcomed.
Well, I started out trying the submodule approach, but as you've found,
couldn't get it to work cleanly with tags and branches. I load Dojo as a
submodule in my own projects, and yes, what you get in the main project
is a commit id. When you update the submodule (using git submodule
update in the master project), it'll check out that particular commit,
without putting it on a branch.
I used a similar strategy, only instead of using a submodule for each
project, I used a branch for each project. And then I created a master
branch that used the "subtree" merge strategy to combine the trunks of
each project into the master branch. You can still check out the
individual projects directly--but you still have trouble getting a
tagged version of the project, or a branch.
I think the real problem here is the Subversion layout. It's a problem
even in subversion--there's no clean elegant way to switch between a
particular tag and trunk, if you want dojo, dijit, and dojox. This
really complicated my development process, especially when I had to
start backporting patches to a tagged release. The cleanup I did in git
really solved all these issues in our development.
The svn book recommends either having tags, trunk, and branches at the
top level of your repo, with individual projects as subdirectories; or
having projects at the top level of the repo, each with tags, trunk and
branches inside the project directory. Dojo's svn does both, making it
completely mixed up -- code for tags and branches are stored in a top
level tags and branches directory, with each project inside it, but
trunk code is all in top level individual project folders, with a trunk
directory inside it! That's the whole problem. Pick one or the other, or
else we're stuck with a Frankenstein monster of a git mirror, or a
really messed up development process too.
So my suggestion is, fix Subversion first! Then your (and my) git mirror
can get much simpler, and you'll make it easier for all the new users to
test trunk in the process.
Two real options for this:
1. Project oriented. In the svn repo, move tags/release-1.3.1/dojo (and
all of tags/*/dojo) to dojo/tags/release-1.3.1. Move branches/1.3/dojo
to dojo/branches/1.3. Now you have independent projects, each with
trunk, tags, and branches all under one path, easy to split
out/clone/whatever.
2. Release oriented. (my preference--I still see these projects as going
together). Move dojo/trunk to trunk/dojo, dijit/trunk to trunk/dijit,
etc. Now users can check out trunk and see all projects, with exactly
the same layout as checking out branches/1.3 or tags/release-1.3.1. This
makes it much easier to switch between trunk and a tag.
Either way makes mirroring in git much, much easier. The first lends
itself to submodules, and would make it easier for 3rd party projects
and things like plugd to get distributed alongside dojo. Sounds like the
direction the project is heading.
Cheers,
John Locke
http://freelock.com
-------- Original Message --------
Subject: Re: [Dojo-interest] ANN: Dojo on github
From: Eugene Lazutkin <eugene.lazutkin@...>
To: dojo-interest@...
Date: Thu 25 Jun 2009 02:29:22 PM PDT
> I didn't import branches and tags to avoid facing the non-standard SVN
> setup used by Dojo. ;-) I added some tags manually (0.9.0b-1.0.2), and
> still plan to experiment with branches and tags.
>
> Thank you for the link to your notes on the setup. I appreciate that you
> took time to write them --- clearly I don't want to reinvent the wheel.
>
> Incidentally I planned to blog on the mirror setup too, but now I will
> postpone it until I try to incorporate branches and tags.
>
> I have a git two-way mirror for Dojo for over a year now. But there are
> two sticky points I have noticed since mirroring to github:
>
> 1) Branches.
>
> For my work I don't need anything but trunk. For branches like "1.3" I
> just clone the branch in a new directory as a trunk and work separately
> with it.
>
> For the mirroring we decided to have separate repositories for Dojo,
> Dijit, DojoX, Util, and Demos. The underlying ideas were:
>
> a) Some people want just Dojo and nothing else, or Dojo + Dijit, or Dojo
> + DojoX + Util, and so on. For example you don't mirror Demos, and this
> should be totally fine --- there are many reasons to track projects
> separately. Having different repositories provides for that naturally.
>
> b) Some day we will want to separate release schedules of these
> projects. I suspect that we will have some synchronization points, like
> major releases, but minor releases like bug fixes can be produced on as
> needed basis by individual projects.
>
> 2) Tags.
>
> The existing Dojo SVN setup introduces a lot of complications because it
> uses a single server to track everything. For example, the release
> manager decided to tag a release, say, "1.3.2". It may fall on a
> changeset, which is not tracked by a particular repository or their
> combination.
>
> Of course we can tag a point in time, but branching introduces problems.
> Example: somebody working on the trunk modified a certain module, later
> on a problem was found and a fix was created, now the release manager
> wants the fix in the "1.3" branch but without new functionality. It
> means when we are ready to tag "1.3.2" we will tag the branch, not the
> trunk.
>
> Who cares about tags? github does. For every tag it creates a download
> completely automatically (see: http://github.com/dojo/dojo/downloads). I
> want it to be coherent and consistent.
>
> ===
>
> Ideally I want to address both problems, yet continue to maintain
> separate repositories.
>
> Maybe it makes sense to create a super repository to unite all projects
> under one roof. Will Riley proposed to do it with submodules. Sounds
> simple, but as far as I remember with submodules you can refer to a
> particular commit in an external repository, but I want to track live
> (the latest). Any ideas about that are welcomed.
>
> Thanks,
>
> Eugene Lazutkin
> Dojo Toolkit, Committer
> http://lazutkin.com/
>
>
> On 06/25/2009 03:30 PM, John Locke wrote:
>
>> Happy to see this! Good start guys.
>>
>> I do notice that the git repositories only mirror trunk, right? I'm not
>> seeing any tags or branches.
>>
>>
>> For an alternative approach (and many of you know about this already),
>> I'm also providing a git mirror of the dojo svn repository. I've done a
>> fair amount of wrangling to get the dojo, dijit, dojox, and util
>> repositories imported into a single branch on one repo, with the same
>> layout as you get in a tag or branch. This makes it very convenient to
>> switch between trunk and a specific tag.
>>
>> I'm going to write up and post a summary of our workflow on my blog
>> soon, based on an earlier thread about managing dojo builds. But
>> meanwhile you can clone my git repo at
>> git://git.freelock.com/git/dojo.git, and browse it at
>> http://git.freelock.com/?p=dojo.git;a=summary . Or you can replicate our
>> setup using my notes, http://freelock.com/kb/Git
>>
>> Our git mirror gets updated from svn automatically every 6 hours. Use
>> the "master" branch for trunk of all 4 projects (I haven't included the
>> demos trunk). Use dojo-trunk, dijit-trunk, dojox-trunk, and util-trunk
>> branches as equivalents of the "official" git release. You should be
>> able to format patches based on these branches to commit back to svn...
>>
>>
>> Cheers,
>> John Locke
>> http://freelock.com
>>
>> -------- Original Message --------
>> Subject: Re: [Dojo-interest] ANN: Dojo on github
>> From: Matthew Weier O'Phinney <matthew@...>
>> To: dojo-interest@...
>> Date: Tue 23 Jun 2009 08:36:19 AM PDT
>>
>>> -- Peter E Higgins <dante@...> wrote
>>> (on Tuesday, 23 June 2009, 11:24 AM -0400):
>>>
>>>
>>>> This concern was brought up at the last meeting. We made note explicitly
>>>> that any decision to change the VC core would be preceded by much
>>>> documentation and testing beforehand. There will be no surprises, and IF
>>>> it were to happen, we'd provide a crystal-clear migration guide.
>>>>
>>>> This GitHub thing, as Eugene points out, is experimental and
>>>> unidirectional at the moment. There simply was a tremendous amount of
>>>> interest in allowing folks to get Dojo from a git repository, as it is
>>>> an exceptionally popular DVC these days.
>>>>
>>>>
>>> Perfectly understandable, and something we're considering ourselves
>>> (lots of contributors are interested in using Git, and I myself
>>> personally mirror all the ZF repos locally as git repositories to
>>> facilitate experimental branching and offline commits).
>>>
>>> Thanks for the clarifications, everyone, and very excited to see another
>>> project using git!
>>>
>>>
>>>
>>>
>>>> Eugene Lazutkin wrote:
>>>>
>>>>
>>>>> No current plans to move the primary from SVN to any other SCM.
>>>>> Obviously the official mirror on github is the exploratory move, but any
>>>>> decision to move (if any) will be taken after we gather some experience
>>>>> with mirroring, and we will take into account opinions of all
>>>>> stakeholders and major users. Clearly Zend is included, and we don't
>>>>> plan to leave anybody hanging.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eugene Lazutkin
>>>>> Dojo Toolkit, Committer
>>>>> http://lazutkin.com/
>>>>>
>>>>> On 06/23/2009 07:00 AM, Matthew Weier O'Phinney wrote:
>>>>>
>>>>>
>>>>>
>>>>>> -- Eugene Lazutkin <eugene.lazutkin@...> wrote
>>>>>> (on Monday, 22 June 2009, 10:55 PM -0500):
>>>>>>
>>>>>>
>>>>>>
>>>>>>> As of now all five major Dojo repositories are available on github as
>>>>>>> official mirrors: http://github.com/dojo
>>>>>>>
>>>>>>> http://github.com/dojo/dojo/tree
>>>>>>> http://github.com/dojo/dijit/tree
>>>>>>> http://github.com/dojo/dojox/tree
>>>>>>> http://github.com/dojo/util/tree
>>>>>>> http://github.com/dojo/demos/tree
>>>>>>>
>>>>>>> All mirrors are read-only. No branches (save for master) are mirrored. I
>>>>>>> plan to add tags later.
>>>>>>>
>>>>>>> For now I will update mirrors manually 1-2 times a day. Later it will be
>>>>>>> automated, but in any case expect a lag --- our Subversion repository is
>>>>>>> still the primary.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Will Dojo be migrating entirely to Git at some point, or will github
>>>>>> simply be a mirror, allowing contributors to push via git+svn?
>>>>>>
>>>>>> I ask as a move to git would require some changes to Zend Framework
>>>>>> infrastruture, as we currently pull in Dojo via svn:externals. :)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> FAQ: http://dojotoolkit.org/support/faq
>>>>> Book: http://dojotoolkit.org/docs/book
>>>>> Forums: http://dojotoolkit.org/forum
>>>>> Dojo-interest@...
>>>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Peter E Higgins
>>>> Dojo Project Lead : http://dojotoolkit.org
>>>>
>>>> _______________________________________________
>>>> FAQ: http://dojotoolkit.org/support/faq
>>>> Book: http://dojotoolkit.org/docs/book
>>>> Forums: http://dojotoolkit.org/forum
>>>> Dojo-interest@...
>>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>>>>
>>>>
>>>>
>>>
>>>
>> _______________________________________________
>> FAQ: http://dojotoolkit.org/support/faq
>> Book: http://dojotoolkit.org/docs/book
>> Forums: http://dojotoolkit.org/forum
>> Dojo-interest@...
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>>
>>
>
> _______________________________________________
> FAQ: http://dojotoolkit.org/support/faq
> Book: http://dojotoolkit.org/docs/book
> Forums: http://dojotoolkit.org/forum
> Dojo-interest@...
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>
> !DSPAM:4a43ec6f248235057925723!
>
>
_______________________________________________
FAQ: http://dojotoolkit.org/support/faq
Book: http://dojotoolkit.org/docs/book
Forums: http://dojotoolkit.org/forum
Dojo-interest@...
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
« Return to Thread: ANN: Dojo on github
| Free embeddable forum powered by Nabble | Forum Help |
