Subversion support

[thebjorn]

This assumes standard svn repository layout (/trunk, /branches, /tags),
and that development is done on either trunk or branches.

[peritus]

Hm ?

[thebjorn]

Hm indeed.. It was added by the GitHub windows client... (I'll remove it).

[peritus]

This needs tests and documentation.

[thebjorn]

Ok. I'll see if I can't add tests + docs sometime later today or tomorrow.

[thebjorn]

So I'm looking at the tests, and they're taking advantage of the fact that git and hg have very similar command syntax, so parametrizing on the command name makes sense. They all start with:

tmpdir.chdir()
check_call([vcs, "init"])

similar functionality for subversion would be

svnadmin create --fs-type fsfs some-other-dir
cd ..
svn import tmpdir file:///some-other-dir/tmpdir -m ""
rm -rf tmpdir
svn checkout file:///some-other-dir/tmpdir tmpdir
cd tmpdir

I see a couple of places where there are if vcs == "git", but obviously the above would be too much to put into every test function..(?)

A second option would be to write separate test functions for subversion, however, that seems like a bad idea.

A third option would be to parametrize the tests on objects that abstracted the needed vcs functionality (as opposed to strings like it is now), i.e.

class Git:
    def __init__(self, directory):
        directory.chdir()
        check_call(["git", "init"])
    def list_tags(self):
        return check_output(["git", "tag"])

@pytest.fixture
def git(tmpdir):
    return Git(tmpdir)

class Hg:
    ...
    def list_tags(self):
        return check_output(["git", "tags"])

That seems like a very radical change for this pull-request though.

Any advice on how to proceed?

[and1er]

Is it appropriate to separate VCS tests: independent Git, Mercurial and Subversion test could be adaptive for each VCS particular features?

This pull request is pending more than 3 years. Many developers with Subversion still need to write own wrappers for committing and tagging. I'm one of them.

[thebjorn]

I no longer have any interest in this PR. If someone wants to take it over and run with it you're welcome to treat this PR as your own. (FWIW, I now believe it is a mistake to combine upversioning and source tagging..)

[and1er]

@thebjorn, okay, thank you for the response.
I will try to finish PR (or create my own with references to this PR, I haven't done this before). Maybe. Because I actually wrap version bumping by a task and it is more convenient to commit and tag nearby.

[thebjorn]

@and1er if you're doing a PR, it might be better received over at https://github.com/c4urself/bump2version which seems to be under more active development.

ps: if you're using invoke, then you might be interested in the upversion task in https://github.com/datakortet/dk-tasklib/blob/master/dktasklib/upversion.py#L65, usage e.g. inv upversion --minor. It knows about the regular places you'd find version numbers, and can easily be configured

ns.configure({
    'pkg': Package(),
    'versionfiles': [
        'path/to/file/with/version/number.xml'
    ], ...
})

I've also implemented option 3 from above in a project that's not published yet, but if there is interest I can probably publish it early next month..