On Fri, 3 Dec 2004, Dale Worley wrote:
> This doesn't solve the stated problem, but may solve the larger problem:
>
> 1. Check out the file. 2. Add your proposed unique ID numbers. 3. Attempt
> to check in. If the check-in fails, revert the file and go back to 2
> (probably with different ID numbers). If the check-in succeeds, you have
> successfully reserved the ID numbers.
>
> This isn't much different from what your people are doing already, since
> with a lock, if a check-out fails, they have to wait a while and try again.
(Hi, Dale. Funny how my social circles are overlapping like crazy)
It's really pretty different, and let me explain part of the the problem I
neglected to mention.
The unique IDs are not human-allocated, they are assigned by a GUI
development tool (I don't know what it is and have never seen it). That
means that (1) The wall-clock time between getting the file with the UIDs
and being ready to commit it could be substantial, and (2) if the process
fails because someone else modified the file while they were working, the
developer has to redo all their work from scratch.
-------------------------------------------------------------------
DDDD David Kramer http://thekramers.net
DK KD
DKK D "Remember folks - Traffic lights timed for 35 mph
DK KD are also timed for 70 mph."
DDDD Jim Samuels
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 3 17:02:36 2004