2

I have an SVN repository that has 

trunk/file1.txt
trunk/file2.txt
trunk/fileR.txt

On the server, I have a working copy checkout of trunk ( /var/www/trunk ) owned by user www-data .

fileR.txt is read only for everyone except the user www-data (access restricted by authz or svnlook author). fileR.txt should be generated by concatentating file1.txt and file2.txt: cat file1.txt file2.txt > fileR.txt

What I want is that every time there is a commit on either trunk/file1.txt or trunk/file2.txt, a script should be run that updates the working copy on the server, concatenates the files and commits the new fileR.txt to the repository.

What I had in mind was a post-commit hook that does all of the above, but I am not sure if and how SVN can handle a new commit until the previous commit has been finalized.

Example: So, commit1 with changes to file1.txt comes in, pre-commit hook runs (if any), transaction is committed to the database and then the post-commit hook runs. The post-commit hook actually creates a commit2 that needs to finalize before the post-commit hook from commit1 will actually finish.

Is SVN capable of doing this? If not, what other tools / workflows do you suggest?

Thanks

cdavid
  • 497
  • 6
  • 11
  • 1
    Typically, if a file can be derived from other files in the repository, you don't commit that file to the repository at all. Anyone needing that/those file(s) can derive it on demand. Why do you need to store the fileR file in the repository, when you can simply concatenate the other two to get it? – Lasse V. Karlsen Dec 11 '11 at 01:07
  • One question: why does fileR need to exist? Can users not work with file1 and file2 separately? I think a bit more context is needed to work out why you want to do this -- it just seems odd to me. – Chris J Dec 11 '11 at 01:21
  • `fileR` needs to exist for legacy reasons. In our research group, we use BibTeX to produce all the references in our papers (this is fileR). Recently, we realized that keeping `fileR` with both papers published by us and papers published by others is not a good idea and switched to two separate files (one for us, one for the rest of the world). Unfortunately, we use some scripts to automatically generate publication lists for individual people in the research group (that I would not like to change). But we still want to keep the legacy file. – cdavid Dec 11 '11 at 02:00

1 Answers1

1

Let's say you make a post-commit hook to do what you want...

  1. I commit a change in file1.txt.
  2. Post-commit hook picks up the change, and creates a new file fileR.txt
  3. Post-commit change commits this change which causes your pre-commit hook to fire.
  4. And, you're right back to Step #1

There's also the issue of creating a working copy on your server where your post commit hook can operate. When someone does a commit, you'll have to either update or even checkout a working copy on your server, concat the changes, and then do a new commit without firing your commit hook. Remember, people might create branches, so you may have to have multiple working copies.

And, while your post-commit hook is doing all of this, you users have to wait for the post-commit hook to complete.

Plus, if I do a commit, my working copy is now out of date. I now have to commit, then do an update because the server did a commit.

I hope I've convinced you that this isn't a really good idea. It is possible, but it certainly isn't advisable. In fact, if I saw a build engineer do something like this, I'd fire them.

I suggest you take a look at Jenkins. Jenkins is a continuous build server. What you can do is have Jenkins create your fileR.txt file for you whenever a commit is done. This file can be easily downloaded from the Jenkins server and be made publicly available. You can also maybe take your fileR.txt and create the PDF for people while you're at it.

So, your combined file is still available and can be downloaded by your other processes, but it won't cause your post-commit hook to fire another round of hooks. And, fileR.txt is read only by everyone who has access to that particular Jenkins job.

David W.
  • 105,218
  • 39
  • 216
  • 337