[ANN] Scmproj 0.5 released

[Alexander Belchenko]

Paul Harris пишет:
> 
> 2009/12/6 Alexander Belchenko <bialix at ukr.net <mailto:bialix at ukr.net>>
> 
>     Paul Harris пишет:
> 
>     > As a side-note,
>     > I currently have a system where I keep ALL my projects in one
>     repo, and
>     > I have a subdirectory called eg 20090601 where I put all the branches
>     > for components in there (including eg the boost sources), for a
>     'stream'
>     > of development.  I can check out all the branches in that subdirectory
>     > into another repo (with trees) and do the work in there....   If I
>     do a
>     > major release of my app that relies on certain versions of libraries,
>     > then I start again with a new subdirectory in the main repo with a new
>     > date.   Extra branches are cheap as theres a lot of shared history.
> 
>     The point of my scmproj is ability to create big project from the
>     set of related branches.
>     Or build final installer from several projects collecting them into
>     another integration superproject.
> 
>     Are you using the date-folder to keep working state of all
>     components together?
> 
>     Yes, there is unfinished feature in scmproj called snapshot which
>     should remember this data for you
>     automatically when you commit entire project. I'm working on it now,
>     because it's very critical for
>     me. Today I'm using tags to "snapshot" related branches. But tags
>     very limited in bzr, so I need
>     real snapshots anyway.
>  
> The date-folder also provides a home for all the current Tips for that
> version of software.   Really, the date-folders should be named after
> project versions.
> eg "v3" subfolder may contain boost 1.33.1, qt 3 and my v3 of software.
>   I can merge patches into the various components and build the v3
> software with the old combination of components.
> Then "v4" subfolder has boost 1.40.0 and QT 4.   I can merge patches
> from the v3 subfolder if I want.
> So if I want to create a fresh build environment on a new computer, I
> just check out all the branches inside a particular subfolder and
> perform the build procedure.
> 
> I also have a "master" subfolder which contains all the tips and various
> branches of all the components.

> So if I upgrade a component, i'll push the new version to the tip branch
> in "master", plus create a new versioned-folder in "master"  eg
> master/component_tip  and  master/component_1-2-3
> 
> Then I go to my particular build environment (eg a clone of all the
> folders in "v4"), and bzr merge from master/component_tip, then check it
> in and upgrade the rest of the software to fit the new component.  Last,
> the changes are pushed back to the branch in the "v4" subfolder.
> 
> So its not quite what I'd call a snapshot... its more like two
> independent bundles of branches that evolve independently.  Occasionally
> I might merge between v3 and v4.
> 
> Is this what you are doing?

Well, more or less. Snapshot just remember what was the state of entire project at any given point
of time when you commit entire project. So if you need to recreate your v3 or v4 project in the
state as it was month ago, you get this easily with snapshots. How you handle this situation with
your dates-folders? Create as much folders as you need checkpoints? This seems like step backward.
I understand your scheme with v3, v4 and current-tips and it makes sense even in the terms of
scmproj. Snapshots are just remember history of your changes in another dimension (time).