CVS Via E-Mail?

krogoth asks: "I'm working on a project with another programmer from Germany, and I and the person who runs our CVS server are in North America. This means that in the last 1-2 months, the other programmer and the CVS server have been online once, and that's not good enough. Is there any way to access a CVS server while it's offline (or at least have a commit/update ready to go)? The easiest way I can think of to do this would be e-mail... but then I don't have the time or knowledge to find out how to modify the server. The CVS server is running on Windows." Now this is an interesting idea. How difficult would it be to change the CVS client and daemon so that it would be possible queue up commits thru e-mail when the server is unavailable? Would any of you find this useful?

CVSQ

[velkro]

CVSQ, or CVS Queued might solve your issues. It doesn't work over email, but it allows you to quere up commits until the CVS server is available again.

Ask Slashdot seems to be for people who haven't found www.google.com [google.com]...

well, not directly what you asked, but...

[StandardDeviant]

OK, so I know this isn't really an answer, but have you considered making a project on sourceforge? It would take care of all the stuff you needed to host the project (CVS, bug tracking, blah blah, you know the drill). Plus it's got a slightly better uptime/availability that some random Windows machine... ;^)

WRT to the question itself, I'm not very familiar with the workings of CV, but speaking in the broadest sense of theory I could see how this might be doable using email, in that the message subjects could contain he codes neccessary to make the storage program interpret which message contains what, and the diffs could be attachments. This could also be non-trivial to program (i.e. me doubting CVS can do this normaly you may have to code up something that's ``really CVS-like'' from scratch (probably in perl because there exist plentiful tools native to the language and module base that would make this task easier than C or whatnot), like do you go on sent-time or receive- time to determine which diff came in ``first'' and represents an earlier version number?

Anyway, good luck!

--

Re:What's this?

[StandardDeviant]

Well, use a non-silicon patch mechanism. In other words, only one person at a time has the ability to modify the source package through some arraingment between the participants. Like how a token ring lan works. Kludgy, yes, but platform independent and doesn't use sourceforge. :-) (Perl used somethign similar for a while back in the early 5.x days called the ``patch pumpking'' whereby only one person at a time had the ``patch pumpkin'')

Shrug. Restricting yourselves to win32 and private server leaves you with a pretty small solution space. Anyway, good luck!

--

CTM

[elbuddha]

CTM [freebsd.org] does this.

Server side, the CTM server runs a script which identifies changes, compresses them, puts a sequence number on them, and emails them out. Client side, ctm.rmail decodes and applies the changes.

CTM was developed for use with FreeBSD, but could be used for any source repository.

Re:What's this?

[ivec]

For a non-free project, I guess you will want to consider a non-free product:
Code Co-op (www.relisoft.com) does provide an email-based source control system for Windows (+ a Linux beta). An automatic 'dispatcher' tool emails the scripts out and processes them in.
It also lets you use your preferred tool to zip and encrypt the scripts before they are sent.

It worked for me on a project with remote developers, with only few technical quirks - but it's really easy to use. Licenses are up from USD 50 per developer, email support was good.

NB: I have no financial interest in the tool.

hth -ivec

Moving the server is easy

[not_the_resurrection]

If the server is going to be down for a prolonged period just move the repository to a new machine. All that is required is copying the repository directories to a new machine and configuring an access method on that machine, i.e. pserver, kserver, sshd, etc. There is nothing in the repository itself that is specific to the server. This is a painless process that I've done a few times with projects I've been involved with. There are variations on this. If the server is lost without warning, set up a local server, import your project(s), and retire the old server or copy diffs when server comes back. This can get ugly real quick. IMHO, the notion of using email sounds like a complete nightmare. Handling multiple code collisions via email? The basic system with interactive commits and updates is easy to understand and forces users to deal with collisions early.

Re:well, not directly what you asked, but...

[krogoth]

I don't have the time or knowledge to find out how to modify the server, so i obviously can't rewrite it :)

Re:CTM

[krogoth]

This helps a lot, but, as I said, the server is windows, and I don't think it's possible to get it to linux or FreeBSD. How hard would it be to get it running on windows? or am I missing some part of the documentation that obvious to every linux programmer who doesn't want to hear about windows?

Re:duh

[krogoth]

"A first post _15_ minutes after the article went up. that's sad. Ask Slashdot is such a ghetto. Perhaps its because the people asking the questions never tried a search engine."

Or because I didn't make it to the front page... i'm surprised someone like you went to all the trouble of looking through the section pages to post useless messages.

What's this?

[Electrode]

Yo all. I am the guy that runs the CVS server kro was talking about. I -could- install Linux on this sys and run something from there, but I really don't want to.

So, any ideas for something like that? We really don't want to use Sourceforge or things like that, as we need to keep the code strictly between us. I'm not a programmer, so I could never make a change to the server code and have it compile and work.