Yeah, I was afraid of that. I can see svn operates a bit differently.
Therefore, old scripts cannot be easily transfered.
I do not like the check-and-reject idea because it would imply the
scripts be run locally. Which means they would need to be distributed
to local clients. That's rather ugly.
I do not really like those cron jobs if I can avoid them. I know it
works, but it's a catch-up game. Alternatively, I could do a server
that gets kicked-off by a hook. That could almost pass as an
'implementational detail' of the good old check-in triggers.
But I just can't help the feeling the necessary mechanisms are already
available. Consider what happens when a check-in is rejected due to a
'conflict'. If this is already done, then all we need to do is to add a
hook that would add the copyright, proceed with check-in, but return a
"conflict". The user would then be forced to synchronize its local
cache. I think it could be done without breaking the atomicity of
transactions. The reutrn code could come back with a diff info which
would allow the client to update its cache and consider the transaction
successful.
Finally, maybe all I need to do is to use a post-commit hook to run a
checkout-modify-checkin cycle. I would need to be able to deduce all
checked-in files. That may be the simplest method at this point.
m christensen wrote:
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 8 01:03:59 2004