Software configuration management

to quote wikipedia:
Software Configuration Management (SCM) is part of configuration management (CM). Roger Pressman (in his book) Software Engineering: A Practitioner's Approach, says that software configuration management (SCM) is a "set of activities designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made." In other words, SCM is a methodology to control and manage a software development project.

SCM concerns itself with answering the question: somebody did something, how can one reproduce it? Often the problem involves not reproducing "it" identically, but with controlled, incremental changes. Answering the question will thus become a matter of comparing different results and of analysing their differences. Traditional CM typically focused on controlled creation of relatively simple products. Nowadays, implementers of SCM face the challenge of dealing with relatively minor increments under their own control, in the context of the complex system being developed.

Name Changed
Comments 1

Müller's avatar

expeehaa wrote about 1 month ago

Since there are already other mercurial extensions in this project, I’ld like to move the hg-git extension for mercurial here. I originally submitted it to devel:languages:python as "python-hg-git", but I now think that this is not the correct place.

However, hg-git requires dulwich>=0.19.0, which is not available in the default Leap repositories, but only in devel:languages:python. To build it here for Leap, the devel:languages:python project would need to be referenced in Leap repositories. I don’t think that this is desirable for all the packages in this project though.

If the maintainers here agree with moving hg-git (or at least having it here), would creating a child project (e.g. devel:tools:scm:python, there is probably a better name) be possible and acceptable?

You can find an example of how I imagine the project and package here:

Regarding the naming of mercurial extensions, the current standard (if there is any) seems to be simply the name of the extensions python package. I think it would be a good idea to make it clear that the packages are extensions for mercurial and not some standalone tool, which is why I would suggest to prefix the name with "mercurial-extension-", similar to, for example, gnome shell extensions (gnome-shell-extension-...). I already did that in the package linked above.

I hope this is the right place for such a request, I couldn’t find a better way to do it.

openSUSE Build Service is sponsored by