pipeline progression isn't versioned
Bug #497614 reported by
Paul Hummer
This bug affects 3 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| bzr-pipeline |
Confirmed
|
Low
|
Unassigned | ||
Bug Description
I was talking with Stephen Warren last night, and he explained that one thing he liked about looms that pipeline doesn't support is the versioning of the pipeline evolution. For instance, he wanted to be able to see that at revno 5 one pipe A, the next pipe changed from pipe B to pipe C because a pipe C was inserted then.
I'm not sure I really have a use for it, but he suggested it, and if it's easy, it might be a good idea to implement.
Revision history for this message
| Stephen Warren (srwarren) wrote | #1 |
| Changed in bzr-pipeline: | |
| status: | New → Confirmed |
| importance: | Undecided → Low |
To post a comment you must log in.
FYI, I see this as basic functionality.
bzr itself maintains complete history of the file/directory tree in a branch; I can "sync" back to any point in time and get an exact replica of the tree. Or, I can use various tools to browse the development history, see commits, diffs, etc.
One way I look at this is that bzr versions a tree of directories that contain files; many other VCSs version a set of files that happen to be in a tree. bzr allows merge conflicts to be detected on directories for example.
For pipelines, I see versioning the set and order of pipes as the exact same concept as versioning of directories in a branch. In other words, part of the state of the pipeline at any given time is the set of pipes that are in the pipeline, and their "stacking" order. bzr should version all state that it knows about. Irrespective of use-cases, I believe a VCS should version all this state simply for historical research purposes; when did I add a new pipe, why (i.e. what does the commit message say for adding the pipe), etc.
As a use-case, suppose I have a pipeline that contains Ubuntu packaging. The pipeline might represent the trunk distro's packaging (Lucid right now). I might want to go back and make some change specifically for Jaunty, after I've already committed some changes for Lucid that I don't want in Jaunty. With a single bzr branch, I'd just branch Jaunty from a point in the past. I want to be able to do the same with pipelines; go back to a previous state of the entire pipeline and branch that, rather than having to create a new pipeline and manually branch the individual pipes into it (if that's even possible).