Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Oct 5, 2012
  1. @galthaus
  2. @galthaus
Commits on Oct 4, 2012
  1. @VictorLowther

    Make push_release work.

    VictorLowther authored
  2. @galthaus
  3. @galthaus
  4. @galthaus
  5. @VictorLowther
  6. @galthaus
Commits on Oct 3, 2012
  1. @galthaus
Commits on Sep 28, 2012
  1. @VictorLowther
  2. @VictorLowther
  3. @VictorLowther
  4. @VictorLowther
  5. @VictorLowther
  6. @VictorLowther
  7. @VictorLowther
  8. @VictorLowther

    Add hierarchy back to builds in releases.

    VictorLowther authored
    This adds the notion of hierarchy to builds within a release.
    If a build has a symlink named "parent" in its directory, then it will
    inherit barclamp metadata from the build that the parent symlink points to.
    
    This patch also adds more paranoia when doing builds using a git
    managed build cache.
Commits on Sep 24, 2012
  1. @VictorLowther
Commits on Sep 21, 2012
  1. @VictorLowther
Commits on Sep 20, 2012
  1. @VictorLowther

    Speed up ./dev fetch

    VictorLowther authored
    Parallelize fetches by barclamp instead of fetching each
    barclamp/remote combination in serial.
Commits on Sep 19, 2012
  1. @VictorLowther

    Relax cleanliness restrictions for the main Crowbar repository.

    VictorLowther authored
    This allows sync to just sync barclamps if the top-level Crowbar repo
    is dirty, and has pull-requestd-prep only deal with barclamps for now.
  2. @juddmaltin-dell
Commits on Sep 14, 2012
  1. @VictorLowther
  2. @VictorLowther
  3. @VictorLowther

    Make sure we pick up the barclamp's origin remote and urlbase.

    VictorLowther authored
    We weren't grabbing them properly when clone_and_sync_barclamp did not
    clone a barclamp.
  4. @VictorLowther
  5. @VictorLowther

    Epic dev rewrite to rationalize remote, release, and branch handling.

    VictorLowther authored
    This patch migrates dev from repo metadata v.1 to v.2.
    The following big changes are present:
    
     * Uniform remote handling across all Crowbar repositories.
       The dev tool now enforces that git remotes across all Corwbar
       repositories point at the same thing.  All remote handling should
       be performed via ./dev remote commands, and not git remote
       commands.
     * Remotes are priority sorted.
       Each remote managed via dev has an assigned priority from 1 to
       100, the lower the number the higher the priority.  The remote you
       cloned Crowbar from (previously known as "origin") has priority 5,
       the remote you back things up to (your personal remote) has
       priority 95, and everything else defaults to priority 50.  Remote
       priorities can be changed on the fly -- see README.dev-and-workflow
       for more information.
     * dev assures that tracking branches point at the proper remotes.
       Local branches that exist in remotes will be configured to act as
       tracking branches pointing at the highest priority remote that has
       that branch. Any time you update a remote (by adding, removing, or
       changing priority) or run a ./dev fetch the tracking branches will
       be updated.
     * dev does not have a hardcoded dependency on dellcloudedge.
       You can clone and setup from any crowbar repository, and dev will
       handle making sure that all the barclamps are cloned from the same
       location.
     * You can push and pull from any remote that comes from github.
       By default, pull-requests-prep and pull-requests-gen will target
       the highest-priority remote.  You can change which remote you are
       targeting with the --to parameter.
     * You can easily merge changes from any configured remote unto your
       local branches.  By default, sync will pull in changes from the
       highest priority remote.  You can change the remote that will be
       merged in with your local branches using the --from flag.
     * Submodules are a thing of the past.
       The multiple branches with submodules model of tracking barclamp
       dependencies for each build was fine when we only had 1 release
       with a few builds, but the overhead of keeping everything
       synchronized became too fragile, leading to easily losing commits.
       Instead, all that tracking information (along with per-build build
       system differences) has been migrated into the releases
       subdirectory of master.  The branching structure for barclamps is
       unchanged, and the tracking info for each build will pull in either
       the head of a release-specific branch in the barclamps, a specific
       tag, or a specific commit.
Commits on Sep 13, 2012
  1. @VictorLowther
  2. @VictorLowther
Commits on Aug 21, 2012
  1. @galthaus
  2. @galthaus
Commits on Aug 11, 2012
  1. improve error message

    cloudedge authored
Commits on Jul 10, 2012
  1. @VictorLowther
Commits on Jun 14, 2012
  1. @aspiers @tserong
Commits on Apr 18, 2012
  1. @VictorLowther
Something went wrong with that request. Please try again.