SVN encourages users to commit consistent sets of modified files (change
sets) by the simple fact it's revision centric.
The basic workflow is :
1. Do some changes (a consistent change set can contain a single file as
well as multiple files)
2. Test the changes
3. Commit the changes (creating a new revision)
At the end of the day, a commit = a revision = a change set.
SVN is also atomic: a commit is processed as a transaction. If anything
goes wrong during the commit, the whole change set is rolled back.
In other words, if a commit is containing changes in multiple files, and if
a single file can't be recorded for any reason (e.g. that file has been
already changed in the repository since the last update of the committer's
working copy), then nothing is committed.
Feature branches are usefull to isolate intermediate commits of complex
change sets. Iin the case of a long development, it allows to commit
temporary "check points" in the repository that could require to be
partially reverted, avoiding to work for weeks without backing up your
These are basic concepts of SVN, I hope I'm not misunderstanding your
As a conlusion:
- SVN provides all required features to enforce a change set policy
- I don't see any other way than a good training and a procedure describing
the expected workflow to restrict users to commit change sets only
PS: dev_at_subversion.apache.org is a mailing list for SVN development
discussions only. Avoid using it for usage questions.
2011/11/7 yerra babji <ybabji.apache_at_gmail.com>
> Is there any way to mandate svn users to check in all the files they
> modified? ( Some times they don't want to check-in some files in that case
> they can revert those files and check all the required files)
> I came across concept of change set to check-in multiple files as a
> bundle( at a time) is there any way to restrict users to check in only
> change sets only. ( getting the effect of transaction set )
Received on 2011-11-07 08:48:06 CET