Be prepared when accidents happen

Locate the best auto rates in your area

Compare Now

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 < matt ... @zend.com > To: dojo ... @mail.dojotoolkit.org Date: Tue 23 Jun 2009 08:36:19 AM PDT -- Peter E Higgins < dan ... @dojotoolkit.org > 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 < euge ... @gmail.com > 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 ... @mail.dojotoolkit.org 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 ... @mail.dojotoolkit.org 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 ... @mail.dojotoolkit.org 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 ... @mail.dojotoolkit.org http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest A release candidate GIT 1.6.3.rc0 is available at the usual places for testing: http://www.kernel.org/pub/software/scm/git/ git-1.6.3.rc0.tar.{gz,bz2} (source tarball) git-htmldocs-1.6.3.rc0.tar.{gz,bz2} (preformatted docs) git-manpages-1.6.3.rc0.tar.{gz,bz2} (preformatted docs) The RPM binary packages for a few architectures are found in: testing/git-*-1.6.3.rc0-1.fc9.$arch.rpm (RPM) ---------------------------------------------------------------- GIT v1.6.3 Release Notes (draft) ================================ With the next major release, "git push" into a branch that is currently checked out will be refused by default. You can choose what should happen upon such a push by setting the configuration variable receive.denyCurrentBranch in the receiving repository. To ease the transition plan, the receiving repository of such a push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 for more details on the reason why this change is needed and the transition plan. For a similar reason, "git push $there :$killed" to delete the branch $killed in a remote repository $there, if $killed branch is the current branch pointed at by its HEAD, gets a large warning. You can choose what should happen upon such a push by setting the configuration variable receive.denyDeleteCurrent in the receiving repository. When the user does not tell "git push" what to push, it has always pushed matching refs. For some people it is unexpected, and a new configuration variable push.default has been introduced to allow changing a different default behaviour. To advertise the new feature, a big warning is issued if this is not configured and a git push without arguments is attempted. Updates since v1.6.2 -------------------- (subsystems) * various git-svn updates. (performance) * many uses of lstat(2) in the codepath for "git checkout" have been optimized out. * pruning reflog entries that are unreachable from the tip of the ref during "git reflog prune" (hence "git gc") was very inefficient. (usability, bells and whistles ) * rsync:/path/to/repo can be used to run git over rsync for local repositories. It may not be useful in practice; meant primarily for testing. * http transport learned to prompt and use password when fetching from or pushing to http://user @host.xz/ URL. * (msysgit) progress output that is sent over the sideband protocol can be handled appropriately in Windows console. * "--pretty=