Using vault for embedded linux source control?

[mlangford]

We're a small firm that has a Vault repository going back several years. We've recently come under the need to Linux work as well to accommodate the needs of our customers. Linux and Vault aren't immediately hospitable to each other.

We have the mono client working on one of our dev machines for one platform.

We are not sure we can afford to do that on every platform that we need to be able to develop on, but we do need working source control on every platform. Mono is a pretty big dependency (from a configuration/install angle, to a runtime requirement) for us to repeatedly meet it.

We're trying to see if we have to go for a two source control system, or we can successfully use vault to check-in useful and frequent versions for our Linux development.

Here are our requirements that we know of:

Source Control Client can work on or with a variety of Linux systems (including some embedded targets)
Source Control Solution will not fiddle with rwx permission bits or ownership (important for developing and maintaining root filesystems)
Can check in/out files with a minimum of hassle and can use comments
Can be used with a variety of versions of linux (all 2.4 and 2.6 kernels, basically)
Can be used in a directory structure that isn't necessarily wholly owned by vault
Can easily add files from the command line and not have to fiddle with lots of settings per files
Can easily revert from the Linux client
Can view check-in comments from the Linux client
Can easily diff (possibly using a separate windows client).
Will not fiddle with the end of line characters in the file
Will handle the end of line character in the diffs

Can vault do this? Is there some mix of NFS/NIS/webDAV/smb that can allow it to do all of the above via the windows client without trouncing the file permissions? Does anyone have a setup for this?

Also, if anyone has two system repositories that handle this, featuring Vault on the windows side, I'd also like to hear both details and reasons why you went that way.

--Michael Langford


[/list]

[jclausius]

We are not sure we can afford to do that on every platform that we need to be able to develop on, but we do need working source control on every platform. Mono is a pretty big dependency (from a configuration/install angle, to a runtime requirement) for us to repeatedly meet it.

Most of today's Linux distributions have Mono as a part of the installation. I know Ubuntu and SUSE's will be able to use apt-get. I think there is also a yum or RPM for Mono as well. So, depending on your distribution this might not be that big of a deal.

Please note, Vault on non-Windows platforms is restricted to a command line client (CLC). So all commands to access the Vault server will need to be executed through that client interface.

Source Control Client can work on or with a variety of Linux systems (including some embedded targets)

For Vault, this will depend on Mono.

Source Control Solution will not fiddle with rwx permission bits or ownership (important for developing and maintaining root filesystems)

Vault will change User read / write permissions depending on the Concurrent Development style of the user. The rest of the security bits will be based on the user's umask setting.

Can check in/out files with a minimum of hassle and can use comments

Launching the Vault command line with the command "Commit" and the -comment flag.

Can be used with a variety of versions of linux (all 2.4 and 2.6 kernels, basically)

Again, this will be dependent on Mono.

Can be used in a directory structure that isn't necessarily wholly owned by vault

Vault should work just fine here.

Can easily add files from the command line and not have to fiddle with lots of settings per files

With the Vault CLC, you can add files recursively in one command by adding the entire folder structure.

Can easily revert from the Linux client

I'm not sure I understand this question. Could you elaborate on this?

Can view check-in comments from the Linux client

Comments should be viewable from the HISTORY command.

Can easily diff (possibly using a separate windows client).

Vault's CLC will default to using the diff utility based on the Linux distribution.

Will not fiddle with the end of line characters in the file

The Vault CLC can be set to ignore EOL or even transform this. When you choose to use EOL based on the platform, source code can be checked in with a Windows EOL can be retrieved and viewed with native EOL on Linux (and vice versa).

Will handle the end of line character in the diffs

Again, this will be based on the EOL setting used with GET.

If you have any other questions, please let us know.

[mlangford]

mlangford wrote:
We are not sure we can afford to do that on every platform that we need to be able to develop on..
Jeff wrote:Most of today's Linux distributions have Mono as a part of the installation.

This is why the embedded linux issue comes up. We're not using a distribution (its not really an option in embedded space, especially not in the non-x86 embedded space) on the boards. We're bringing up circuit boards and sometimes need to develop things on them. I've not found a mono build process that is simple enough to "./configure && make && make install" on these platforms. I mean, in July for instance, one of the platforms we were writing for was a 2.4.33 terminal running slackware 10 or 11.

While the "just copy them off to check them in" approach seems like it would work, it hasn't so far. We've had two shipping errors have occurred that wouldn't have if we were using a system with a more lightweight client such as CVS that we could statically compile for the platform system.

And I'm not expecting source gear to have a client that can run on all these diverse platforms. I'm looking for solutions that work with shares, etc, to bridge the gap so I don't have to manually configure mono for each platform.

Source Control Solution will not fiddle with rwx permission bits or ownership (important for developing and maintaining root filesystems)
Vault will change User read / write permissions depending on the Concurrent Development style of the user. The rest of the security bits will be based on the user's umask setting.

Is this not settable? Is there not an API hook or something I can use to maintain these? This really kills us as far as the root filesystem goes. There are many unix files that have to have a certain permission, or they silently fail.


mlangford wrote:
Can easily revert from the Linux client
Jeff: I'm not sure I understand this question. Could you elaborate on this?

By revert, I mean the scenario where I say, screw up the file I have on the disk and want to go back to the last version. Or say, I try to revamp a module and want to forget all the changes.


Do you have any history of people using some sort of drive share to get around this sort of issue? Or perhaps light use of some other version control system for which Vault has a good importer?

--Michael

[jeremy_sg]

This may not be of much help to you, but here's a couple more ideas:

With Vault 4.0, we released an Eclipse client built in Java, which would run where ever you can get eclipse and Sun's Java VM to run. Since this is an IDE integration only solution, you may not want it.

There's also the potential to run the Vault Command Line Client which is built on the same jars as the Eclipse IDE client. We haven't yet put that up for general consumption, but we would be happy to help you with that. This would mean that you would only need Sun's JVM installed, which might be easier than Mono.

[jclausius]

We are not sure we can afford to do that on every platform that we need to be able to develop on.

I see your dilemma. jeremy_sg posted about a different solution. It might not work based on your embedded system distro's softwware configuration, but I want to make sure you know there will soon be other alternatives.

Is this not settable? Is there not an API hook or something I can use to maintain these? This really kills us as far as the root filesystem goes. There are many unix files that have to have a certain permission, or they silently fail.

There's not an available API, but we do provide the Vault Command Line Client source code. You could make slight modifications to this code to create a Vault client more tailored to your environment.

By revert, I mean the scenario where I say, screw up the file I have on the disk and want to go back to the last version. Or say, I try to revamp a module and want to forget all the changes.

Yes, a simple GET with the overwrite option will retrieve the file at any specific version.

Note, if you are actually performing GETS on the embedded device you might run into other problems. The Vault client is going to cache files, and other data in the user's HOME directory. Depending on the devices free space (which may be limited), you may encounter other issues with the Vault client running directly on an embedded system.

Do you have any history of people using some sort of drive share to get around this sort of issue? Or perhaps light use of some other version control system for which Vault has a good importer?

I'm not sure this helps, but in a previous life I worked on an embedded application for single board computers (SBC) from Arcom. We did all our testing and development along with version control on a host computer. The SBC Dev Kit came with an emulation environment so we were able to do all our work on that host PC- including version control. Once we had a working image of the binary, we synchronized the binary and supporting files with the SBC.