1

I develop some scripts for data analysis in a small team. For the moment we use SVN, but not in a very structured way. We haven't even looked how to use branches even though we need this functionality.

What do you suggest as the best practice to setup the following system:

  • two code bases (core and plugins)
  • versions can be incompatible to previous scripts
  • sometimes individual features are being developed and not yet finished, while other fixes have to be done urgently to the code

In the end we don't deliver the code as a package, but rather place the Python scripts in some directory (with version names?). Some other python script which serves as a configuration choses the desired version, sets the path to these libraries and then starts to import the modules.

I saw stable releases to be named "trunk" so I did the same. However, no version numbers yet. Core and plugins are different repositories, however we have to match versions for compatibility. Can you suggest some best practices or reference to ease development and reduce chaos? :) Some suggested GIT. I haven't heard about it, but I'm free to change.

Improve this question
5
  • How does the python configuration choose the desired version if you don't use version numbers? Or is that planned operation?
    – Philip
    Apr 2, 2012 at 15:33
  • The configuration is more or less an executable python script itself. I do a dirty hardcoded sys.path.append. Suggestions welcome :)
    – Gere
    Apr 2, 2012 at 15:43
  • Even don't think about Git - it will give your team no benefits, but a lot of headache
    – Lazy Badger
    Apr 2, 2012 at 16:24
  • @Badger: Why would that be? For the moment copying files and keeping tracking of versions is already a pain.
    – Gere
    Apr 2, 2012 at 17:18
  • Because polished workflow with well-designed (with some glitches) tool is better, than exotic perversions with ugly tool, especially with SVN-backend. You problem isn't tools, but chaotic management and planning (from my POV)
    – Lazy Badger
    Apr 2, 2012 at 18:16

2 Answers 2

Reset to default
1

Disclaimer

This answer is not intended to be comprehensive and detailed illustrated textbook from series "... for Dummies", may contain the wrong conclusions from faulty assumptions and involves the reader's own ability to read and understand the documentation

Preface

The proposed solution is based on the following assumptions:

  • core and each plugin are separate independent Projects
  • each Release contain pre-defined arbitrary (able vary from release to release) set of individual Components of strictly defined version

Solution

In suggested solution expected and suggested the usage of such opportunities of SVN, as:

  • Branches
  • Tags
  • Externals

Each Component will give own placement: in can be separate repository or predefined path inside common repo. In any case Solution consists of only linked by svn:externals independent Components. For each Component (by agreement) URL of stable state is determined and fixed for the duration of the development. Under the above conditions, to simplify the notation and understanding of workflow in the future, use the following preset:

  • Each component have own repo
  • Stable point of each component is repo's trunk
  • Repository of Solution hereinafter have name SuperRepo (as opposed to repositories of Components, which have Repo/somestring/ name)

Hereby, our task is: build Repo* for components, build SuperRepo after it, where each folder is linked relevant repo's trunk, HEAD revision (we don't use PEG-revisions in every-day development).

After these steps development continues in the usual manner, for each WIP for components we can use all and any svn-techniques (branching, tagging, merging)

In Release time we must have map: which components and versions of components should (might) be have been included in the release. Version of component may be defined as revision number (inside component repo) or as tag - it does not matter. With this map we can edit SuperRepo's trunk (trunk!) to our needs (add-remove externals, for used in release externals freeze revision by changing external definition: adding PEG-revision for trunk linking or changing URL to corresponding tag) and tag polished trunk of SuperRepo for future reference. Export tag after all for publishing

This way each release will have known set of components in known state and can be easily assembled as Lego

Improve this answer
0

Well, I'm no SVN ninja or anything, but for the two projects, you'd simply have two folders at the top level. Each of those would have some folders:

  • Release, which would have tags or copies of the project that you decided to give a version number to. And you should really start giving them version numbers.
  • Trunk, this isn't the "stable releases" folder, but rather where the main development code lives. At some point you're going to release. You call the current trunk "the release version" and tag it or copy it off to the release folder. At that point in time the trunk and the release are the same, but the trunk keeps growing.
  • Branch, this is where work gets done. If you want to write some code or change something, you copy the trunk off to your own branch, dink with it, test it, (get someone to code review it for sanity), and then merge it back into the trunk. And then retest it.

The releases and tags let you keep track of what version is compatible with what. And the branches should let you develop long-haul items and still make quick urgent bug-fixes.

Haven't tried git yet, it may be fantastic.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.