prometheas / svn-wc-attendant

Deals with your dirty Subversion WC so you don't have to.

svn-wc-attendant

Deals with your dirty Subversion WC so you don't have to.

Introduction

This is a very simple, almost brutish utility that basically takes a "dirty" Subversion repository and just "crams" all changes that svn status finds in a wc directory up into its repository (yep, it's definitely as dirty as it sounds). In a nut, it will svn add all unknown files (?), svn delete all missing files (!), at which point you can then elect to svn commit the contents of the wc directory to the repository.

To be clear, svn-wc-attendant does not check files out of a repository; it's meant to help you deal with your dirty wc directory by getting everything ready for a commit. This is also to say that it does not commit the changes in your wc directory to the repository.

Which is to say that even if this is the module you're looking for, you're almost certainly still going to need something that lets you do all that other stuff.

It literally just saves you the trouble of doing all the adds and deletes.

So if you haven't already picked a full-featured Subversion module out, I could recommend having a look at packages such as svn-interface or svn-spawn (in fact, this project uses the former for its svn status, svn add, and svn delete functionality).

Usage

Usage of this module is quite simple:

var wcAttendant = require('svn-wc-attendant');
var workingDir = '/path/to/wc';

// checkout files from Subversion repo into `workingDir`
// modify some files in aforementioned wc dir

wcAttendant.prepareWcForCommitting(workingDir);

// commit all changes back to repo

In the preceding code sample, wcAttendant.prepareWcForCommitting() is called to svn add any unversioned files and svn delete any files that were deleted. From there, running svn commit on that wc directory will commit all those adds and deletes to the repo.

Contributing

Contributions from the community are welcome! Please note that all pull requests must satisfy the following conditions to be considered for acceptance:

1. Every pull request must include supporting testing code. Every new feature must be accompanied by mocha testing code that verifies the work.

2. Pull requests must pass linting. I've configured an integration with (HoundCI)[https://houndci.com/] that will automatically provide feedback on pull requests that displease the linter.

Getting Started

Because many of the tests in this module deal with a remote Subversion service, its testing suite requires that you've got Docker installed on your workstation. Installation and configuration instructions can vary by platform and your individual needs, so I'll need to take a simplified approach to getting you set up.

For the sake of simplicity, I'll assume you've got Docker installed, and that:

1. You've cloned this repo
2. You've got a docker machine named default
3. You're using the bash shell

Open a bash session and input the following commands to prepare Docker:

$ docker-machine start default
$ eval $(docker env default)

Because the project offers purpose-built containers to run the testing suite, you actually don't even need npm installed on your development machine to test this project! If this is useful (or if you suspect that you might be running into trouble with your npm or node installations or configuration), you'll be able run the complete test suite using Docker directly, as follows:

# run the tests once
$ docker-compose -f test/services/docker-compose.yml run test

# run the tests and keep watching the project JS files to automatically
# test again each time a file is saved
$ docker-compose -f test/services/docker-compose.yml run develop

Of course having npm installed on your workstation allows you run those same containers with much less typing:

# run tests once, via npm
$ npm run test

# run tests each time a file is modified, via npm
$ npm run develop

When I'm working on this project, I execute npm run develop before starting, so that I can get feedback when I save a file that introduces changes that have broken the tests.

Working With the node-host Service Container

In case you're hacking on the project sources such that you find you need to edit files in the test/services/node-host directory (e.g., you need to modify the node-host container definition), you'll need to rebuild the container image. I've included the following scripts:

# rebuild the `develop` container
$ npm run rebuild-develop

# rebuild the `test` container
$ npm run rebuild-test

svn-wc-attendant's Issues

Drop dependency on svn-interface and deasync libs altogether

Version 0.0.2 abandoned svn-interface in favor of using shelljs to execute svn commands directly for the prepareWcForCommitting() method. Since both neither method has the advantage of being async, may as well standardize on one method.

Refactor tests to separate unit tests out from integration tests

Add a wc directory with a few files in it as "fixture" data, and set up the unit tests (e.g., the tests that do not depend on the availability of a remote Subversion repository host) to operate on that wc. After separating the tests into unit and integration, update package.json to define two new scripts:

• test-unit
• test-integration

Finally ensure that test runs both unit and integration tests.

Mocha fails during `npm test` on Windows

Console output below

Removing intermediate container 2d9469958793
Step 6 : COPY fs/ /
 ---> 53e3df714955
Removing intermediate container 516de8de1b9c
Step 7 : RUN chmod -R +x /usr/local/sbin/*
 ---> Running in ecaed8ab2f1c
 ---> b7e1387f9a48
Removing intermediate container ecaed8ab2f1c
Successfully built b7e1387f9a48
Creating services_test_1
Attaching to services_test_1
←[36mtest_1 | ←[0mnpm info it worked if it ends with ok
←[36mtest_1 | ←[0mnpm info using [email protected]
←[36mtest_1 | ←[0mnpm info using [email protected]
←[36mtest_1 | ←[0mnpm info lifecycle undefined~preinstall: undefined
←[36mtest_1 | ←[0mnpm info linkStuff !invalid#1
←[36mtest_1 | ←[0mnpm info lifecycle undefined~install: undefined
←[36mtest_1 | ←[0mnpm info lifecycle undefined~postinstall: undefined
←[36mtest_1 | ←[0mnpm info lifecycle undefined~prepublish: undefined
←[36mtest_1 | ←[0mnpm WARN enoent ENOENT: no such file or directory, open '/var/
project/package.json'
←[36mtest_1 | ←[0mnpm WARN project No description
←[36mtest_1 | ←[0mnpm WARN project No repository field.
←[36mtest_1 | ←[0mnpm WARN project No README data
←[36mtest_1 | ←[0mnpm WARN project No license field.
←[36mtest_1 | ←[0mnpm info ok
←[36mtest_1 | ←[0m/usr/local/sbin/test-project.sh: line 5: ./node_modules/.bin/m
ocha: No such file or directory
←[36mservices_test_1 exited with code 127
←[0m /c/work/checkouts/git/svn-wc-attendant (master)
`

Make Bithound badges "go green"

CI build failing upon attempt to create the `services_default` network during docker-compose

Travis CI builds are failing with the following message:

$ npm test

> [email protected] test /home/travis/build/prometheas/svn-status-sync
> docker-compose -f test/services/docker-compose.yml up test

Creating network "services_default" with the default driver
ERROR: 404 page not found

npm ERR! Test failed.  See above for more details.

The command "npm test" exited with 1.

`npm run develop` is broken

Running npm run develop should automatically run all unit tests, each time a mocha spec file or a JS source file is modified. Instead, modifying and saving any watched file results in the following output from the develop container:

develop_1 | [16:49:36] Starting 'test'...
develop_1 | [16:49:36] Finished 'test' after 2.79 ms
develop_1 |
develop_1 |
develop_1 |   0 passing (1ms)

Add CLI interface

Implement command line interface to make this possible:

$ svn-wc-attendant stage-changes /path/to/wc

Add wc directory validation

Utility should throw an exception when pointed at a non-wc path.