> Is it possible (not necessary with the native svn console client) to
> commit an edited version of a file - which meanwhile was previously
> edited and committed by another user - without any merge due to commit
> conflicts? In fact just overwriting the current version of the file.
It's hacky, but we wrote a client-side program for
our installation that puts the working copy subset
into a state that ensures what's in the working
copy "always wins" when committed (assuming it's
committed immediately after the script).
Ours is a c# command line tool that just executes
a bunch of svn commands (status, add, resolve,
etc) as needed to get us into the state we need.
Our use case was such that it was just
transcoding some database state into revision
control, so our timing needs weren't that strict,
and we were able to do something like:
while true {
svn update
<transcode to working copy>
svn-smart-pre-commit
svn commit
wait for DB change or timeout
}
To handle your exact case:
1. copy the current version to "someplace safe"
2. svn revert the file
3. svn update the file
4. put the file back from "someplace safe"
5. svn commit the file
will work, barring race conditions.
If you can ignore race conditions (or handle
the occassional error from them), then make
that "will work"
> And if yes, will the repository server apply the sent file diff basing
> on the older version of the file (not the current one of the other user)
> to generate the new file?
Using the above method, it will base the deltas on
the other user's edits, somewhat self-evidently.
--Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 22 17:22:00 2007