Vesta supports arbitrarily large packages, but traditionally packages are sized such that typically only one person is actively changing a package at a time. So, for projects which have lots of simultaneous developers this manifests as lots of small packages. Projects which haver fewer simultaneous developers (like the Vesta source itself), packages have tended to be larger granularity.

The reason that Vesta has this usage model is at least partially due to the fact that Vesta has had some limitations which encourage one to use smaller packages. For example, until recently Vesta had no built-in utilities to aid users in merging--Ken's script is an example of a utility that can close the merging gap. Below (in section 2) I discuss a couple more utilities that I am working on to aid in support for big packages.

Another reason that Vesta traditionally uses smaller packages is that it better fits the build-time configuration mindset that is one of Vesta's key characteristics. One can simply select the versions of packages in an SDL model to get the configuration that he or she wants (so long as all the mixing & matching is a package granularity). The larger the package, the more likely a user will need to go "out-of-band" by manually copying files in order to mix and match versions of files.

Why big packages?

The obvious reason to use big packages is that it is more user-friendly for the tastes of some people, at least for the common case of linear development. A user types a single command to get a copy of the entire development tree, edits whatever files they want to edit, and then types a single command to merge the result into the next version of the development tree.

A less obvious reason (but ultimately more important) is that any refactoring (removing/moving/changing directory structure) is *much* easier within a package than between packages in Vesta. This isn't necessarily a knock on Vesta--but for some users refactoring is such a critical function that it needs a graceful solution.

If there were anything worth addressing in a hypothetical Vesta-3, I'd say that it is the tension between wanting small packages (to allow graceful mixing & matching of source files) and wanting big packages (to better support refactoring). That's just one man's opinion, though.

Finally, another really good reason to support big packages is that it directly emphasizes one of Vesta's strengths, its copy on write virtual filesystem. Users of CVS or Perforce (among others) are used to having to wait for long periods of time to sync their client view to the top of tree because their revision control systems rely on physically copying the bits in order to give their users a mutable version of the repository. For some reason these users aren't too impressed by Vesta's navigable immutable filesystem (probably because it requires cd'ing back and forth between that and the mutable version)--but they are really impressed by its ability to fetch a mutable user 'view' of the repository instantly.

How do we support big packages?

These are the features that I think Vesta needs to better support this model. I'm hoping to get some feedback from the experts here on these plans as I go about implementing them: