Updating a file in repository on commit

Hello. I have a task that is currently solved in manual way. I'd like to automate it. The aim is to have 2 files in the repository that store the current revision number: 1 text and 1 image. For now I make these files with simple cmd script manually, that is no problem. There are several ways to reach the aim:

 
1. The easiest one - to update the files on the client side on pre-commit with the script that is used now; then commit the files with others that are changed. 
2. More complicated way - to make changes on the server side. This could be:
    
   1. Making changes to the working copy after each user commit and committing these 2 files on the server side. 
   2. Making changes to the files on the server side during the user commit on the fly. 
    

The reason why I want to make it on the server side is that I need to have the files in the working copy up-to-date without specific scripts and programs on the user side. Ideally, I'd like to have 2.2 way, hiding these 2 files from the log if possible. But I'm not sure, is it possible. I agree on the way 2.1 - it seems much easier to implement. But that will be +1 revision for each user commit. Maybe there is a way to hide those "technical" commits? Way 1 is easiest, actually, it is now used but in manual mode. But user side needs to have specific software installed and on-update script set. I don't want to depend on user side. Thanks in advance for every useful tips and information! Regards, Alex.

Last updated 3 years ago

You can't hide commits. No way to do it. You can change revision properties without increasing the revision number.  Consider making a change on the server side: You definitely *can* automate a full process as part of a hook. Choosing post-hooks means that you can't actually prevent multiple end-user commits from coming in and disrupting your server-side ordering (there is no ordering of post-hook execution). So if your post-hooks run out of sequence then you could end up with your updated files having N-1 when they should have N (or worse). That could be solved by a pre-commit hook that made sure that the R is monotonically increasing (never goes backwards) simply by rejecting the update if it's coming in with N-1 when the current value is N. Notice that the complexity is increasing? Yep.  It's even more complicated if you choose pre-hooks to do work since while the pre-hook is executing the end-user's "svn checkin" command is hung... so this turns into a human interactive bad experience. Pre-hooks are best if they are lean (only check things that are fast to check) and implement policy (they say "yes" or "no" but don't change things). I've seen folks make changes in pre-hooks. It generally takes a long number of cycles to "get right" and, even the, will suffer the user to have to wait.  So I'll go back and question your motivation. Subversion already has a way to seed Revision information into a checked out file in the working copy. See here: http://svnbook.red-bean.com/en/1.8/svn.advanced.props.special.keywords.html  Perhaps that's all you need. As for the binary file (the image), can't that be generated during your build or packaging processing?

DougR;n80655You can't hide commits. No way to do it. You can change revision properties without increasing the revision number.[/QUOTE] OK, not a big problem to see 1/2 trash in log. 

DougR;n80655 So I'll go back and question your motivation. Subversion already has a way to seed Revision information into a checked out file in the working copy. See here: http://svnbook.red-bean.com/en/1.8/svn.advanced.props.special.keywords.html Perhaps that's all you need. As for the binary file (the image), can't that be generated during your build or packaging processing?

 Yes, I know about Rev keyword, but I work with binary files, so I have no place to insert is, so I need a single file with the topmost revision of repository aka GlobalRevision. Also, there's no builds or other processing - files are DWG, ODT, OTS and other. And yes, for now I generate the revision file before making PDF. I can do that automatically on update, but still the file will be only in the user's working copy. [QUOTE=DougR;n80655] Consider making a change on the server side: You definitely *can* automate a full process as part of a hook. Choosing post-hooks means that you can't actually prevent multiple end-user commits from coming in and disrupting your server-side ordering (there is no ordering of post-hook execution). So if your post-hooks run out of sequence then you could end up with your updated files having N-1 when they should have N (or worse). That could be solved by a pre-commit hook that made sure that the R is monotonically increasing (never goes backwards) simply by rejecting the update if it's coming in with N-1 when the current value is N. Notice that the complexity is increasing? Yep.  It's even more complicated if you choose pre-hooks to do work since while the pre-hook is executing the end-user's "svn checkin" command is hung... so this turns into a human interactive bad experience. Pre-hooks are best if they are lean (only check things that are fast to check) and implement policy (they say "yes" or "no" but don't change things). I've seen folks make changes in pre-hooks. It generally takes a long number of cycles to "get right" and, even the, will suffer the user to have to wait. 

 Thank you for this very detail description. Now I'm getting clearer about how to and how not to implement it all. Looks like the right way will be using post-hook with some filtering. Do I need a working copy of the revision file (let's call it Rev.txt) to manipulate? Or can I do it somehow else? As I see it:

 
1. Get current revision number. 
2. Compare it with Rev.txt (it has to be checked out - or checkouted :-D - before manually or automatiacally). 
3. If new rev number is higher
    
   1. Lock Rev.txt. 
   2. Rewrite it. 
   3. Commit. 
    
4. If new one is lower - do nothing. 

Looks OK? :rolleyes:

Note: I missed some complexity above in trying to stop the N-1 being incorrectly "last" above: you can't do that in a pre-hook since in theory a number of pre-hooks could run in parallel and all pass then those updates would be run without constrained order. Some may fail; some may succeed. Still end up with trouble. So, yuck.  You don't need a working copy to obtain the contents of a checked in file: you can use "svn export" to obtain the current file. But if you're going to want to update it then, well, yes, you'll need a working copy.  Also, just FYI, "post-hooks" are not guaranteed to run. They normally run, but OS shutdowns at the right time, out of resource during fork, etc. can mean they won't.  You might want a very simple post-hook to hand off to a queue. Then have the queue do the work using a list. You could even have the queue processor wait some amount of time before doing an update so it doesn't waste effort (of course, nothing is perfect). In any case, when you update the file (lock; update; checkin) then a new revision will be created as well. But you can't guess that the next revision will be Current+1 because, of course, something else could get checked in ahead.

OK, I got it. Actually, CO/CI are made not very often, so I guess it'll be OK with post hooks. First I'll make a simple post-hook logging each CI to a file, then I will know if every hook finished OK. Thank you very much for opening the door wider ;)