Waldemar Augustyn wrote:
> OK, I won't insist on the method but find me a way to do it.
>
> One of the requirements in my systems is to correctly set copyrights
> on every file as soon as it makes it to the system. (Let's not go
> into why this is so). The CVS way is to simply run a script that does
> the dirty work on every check-in. This does not affect local
> clients. I am no expert, but the local clients cannot assume they
> have a current version becuase there could be other developers working
> on the same file.
Well, that is the point.
The local clients are not going to ASSUME anything.
It simply says I 'know' I sent Version 6 of foobar.c to the repository.
I know I have version 6 of the file, I just asked the repository what
version IT has and
IT said it had version 6 therefore I will not update foobar.c.
Subversion doe not pull every file from the repository, it tries to be
smart about it by keeping track of what has
changed locally.
If one file is changed in the repository MY system can sync my working
copy in about 90 seconds.
Pulling my whole tree takes almost an hour, It's rather large.
I'll take intelligent rather then brute force updates any day.
> I think your statement aobut cached .svn info refers to something else.
> Anyway, in case of CVS, the local clients run update to find out
they're out of date.
> I suspect svn behavior is similar.
SVN looks at local and remote historical information.
The original submitting client 'Knows' It already has version 6 of file X
and Version 6 is the current version per the repository, that means it
is already current.
> I do not see any problem with it. (BTW, this used to work on
ClearCase for years without a single glitch)
>
> Now, with SVN, that is not possible. The hooks, that you are
> referring to, do not allow updates to pending transactions, which I
> understand prohibits any file modifications. I am no expert, but I
> thought I saw a note to that effect. I think that would break the
> atomic nature of transactions otherwise.
>
> For the moment, I just want to move my scripts. But if I need to use
> different mechanism that's OK as long as I know which way to go.
>
> Thanks,
> Waldemar
Mucking with code inside that atomic transaction is precisely the problem.
That prohibition you saw is exactly the issue I'm talking about.
It's a highly regarded 'rule', there is nothing to actually stop you
from changing code in a hook anyway.
Aside from the reality of the risks mentioned.
The fact is YOU are changing code here.
Admit that and treat it like any other code modification, don't obscure
it in a developers check-in process.
'I' DIDN'T check in code with your copyright info in it, Your process
changed 'MY' program then checked it in
under MY id with MY now incomplete change description.
I have had these scripts adding copyright info break code in the past.
I can think of two general ways to approach this.
#1 use the hooks to 'Verify' the correct copyright info is included and
reject the entire commit
unless they are there and make the coders fix the problem.
Give them a good template and make them do the job right.
#2A Make the commit hook verify the copyright info and if it's missing
generate a log on the server.
Allow the commit regardless.
Run a scheduled job as often as you like on the server that looks at
that log, finds the files that need to
have the copyright info fixed or added and go update a dedicated local
working copy and then commit those
changes with an appropriate log entry "Automated addition of copyright
info by Daemon." or whatever.
#2B Skip the hooks altogether, Build a local working nightly, scan the
whole thing and update and commit
offending modified files with a log entry as above.
Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 7 23:58:20 2004