AW: RE: pre-commit transaction modification - remove files

Aliasgar Ganiji <mailto:Aliasgar@epicsystems.com> schrieb am Dienstag, 12. Dezember 2006 17:30:

> At the moment I do reject the entire commit, however, this is extreme.
> Say a developer tries to commit 100+ files, carefully selecting these
> files from a list of several other files. However, one of the files
> selected is a rogue file and the entire commit is rejected because of
> one file.

Why are those rogue files not on the ignore list, so accidentially selecting them is rare? The hook is just the security bully that enforces the ignore policy.

>
> QUOTE
> Don't modify an in-progress transaction, especially in the manner
> you're describing. If you do so, the committer's working copy will
> instantly be out of sync with the repository.
> UNQUOTE
> When you mention out of sync, does this mean that the working copy is
> corrupted or is it out of sync similar to when the development is
> actually being carried out. I was hoping that when the user
> is informed
> with a list of rogue files that were not committed the first time, the
> user can modify those files and re-commit them to the repository there
> by syncing the working copy with the repository.

No. Committing is all or nothing. After a successful commit, the client assumes that all files he tried to commit have been updated in the repository. And there is your problem - the client's pristine copy differs from what is in the repository, creating havoc all over the place - the working copy is corrupt (in very nasty and subtle ways). Never modify an in-progress transaction.

regards

felix

-- 
Felix Gilcher
Head of IT Development
Exozet Berlin GmbH
Rotherstraße 20
10245 Berlin
eMail: gilcher@exozet.com
URL: www.exozet.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org