[ANN] Scmproj 0.5 released

[Alexander Belchenko]

Paul Harris пишет:
> I love the sound of scmproj, I could see myself using it.   One concern
> I have is portability of my information.  I have moved from CVS to MCVS
> to darcs to bzr... And I can continue to move to hg or git if need
> be...   But If I start to use scmproj, can I export/migrate my data to
> git-subprojects or something similar?   Or will I be stuck?

Currently scmproj using ini-style based config, which is supposed to be user-editable.
See http://bialix.com/scmproj/docs/project-cfg.html for full description.
There is to much info though, which effectively can be reduced to minimum minimorum like that:

[component "foo"]
RELPATH = lib/foo
BRANCH_URL = bzr://server/repo/foo

Now compare this with .gitmodules syntax
http://www.kernel.org/pub/software/scm/git/docs/gitmodules.html:

[submodule "libfoo"]
        path = include/foo
        url = git://foo.com/git/lib.git

I'm working now on even simpler scmproj design, so my new configs will be much closer to .gitmodules:

[component "foo"]
path = lib/foo
url = bzr://server/repo/foo

I let you decide how hard it would be to migrate these data manually.

> 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.

> It works, but less than optimal.  And should be portable to other
> versioning systems like git, since its an explicit versioning system.

I don't understand your point. Of course git is great. But I'm using bzr and therefore optimize my
plugin for such system, because all other systems (git/hg) have their own native solutions.