You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by yerra babji <yb...@gmail.com> on 2011/11/07 06:53:47 UTC
Check-in all files at a time?
Hi,
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 )
Thanks,
Babji
Re: Check-in all files at a time?
Posted by Ludovic Lambert <lu...@gmail.com>.
Hi Yerra,
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
changes.
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature
These are basic concepts of SVN, I hope I'm not misunderstanding your
question.
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@subversion.apache.org is a mailing list for SVN development
discussions only. Avoid using it for usage questions.
Regards,
Ludovic
2011/11/7 yerra babji <yb...@gmail.com>
> Hi,
>
> 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 )
>
> Thanks,
> Babji
>
Re: 1.7.1 working copies - verification
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
The real answer is "Run tools/dev/wc-format.py".
If you can't do that, look for **/.svn/wc.db. In 1.7, the shell command
% sqlite3 .svn/wc.db 'pragma user_version;'
returns the magic number SVN_WC__FORMAT_NUMBER == 29.
Joe.Floeder@sungard.com wrote on Mon, Nov 07, 2011 at 20:50:10 +0000:
> How do know I have a 1.7.1 working copy? Can I tell by looking at the working copy on the file system? The older version had .svn directories and the entries file. What does the new working copy look like?
>
> We are running 1.7.1 and 1.6.17 on two different servers - right now I am not sure I am connecting to the correct svnserve process.
>
>
RE: 1.7.1 working copies - verification
Posted by Jo...@sungard.com.
-----Original Message-----
From: Markus Schaber [mailto:m.schaber@3s-software.com]
Sent: Tuesday, November 08, 2011 1:40 AM
To: Floeder, Joe; users@subversion.apache.org
Subject: AW: 1.7.1 working copies - verification
Hi, Joe,
Von: Joe.Floeder@sungard.com [mailto:Joe.Floeder@sungard.com]
> How do know I have a 1.7.1 working copy? Can I tell by looking at the working copy on the file system? The older version had .svn directories and the entries file. What does the new working copy look like?
Normally, 1.7 working copies only have .svn directories in the top level of the working copy. (Externals and nested WCs are different cases.) This should be enough for a first-glance 1.7.X vs. 1.0.X-1.6.X disambiguation.
> We are running 1.7.1 and 1.6.17 on two different servers - right now I am not sure I am connecting to the correct svnserve process.
As both the 1.6.X and 1.7.X clients can connect to both 1.6.X and 1.7.X servers, and the server repository format did not change between 1.6.X and 1.7.X, so I'm not sure which problem you want to describe me with that sentence.
Markus
Hi Markus
Daniel Scahaf answered my question on an earlier reply saying "look for **/.svn/wc.db." Now I see that 1.7.1 working copies only have one .svn folder and the sqlite database file wc.db is in that folder.
After I realized this, I discovered that we were sourcing in a path to an older version of svn in our unix shell script 'wrappers'. I changed the environment variable assignment to version 1.7.1 and now I get the newer version of the working copy. Thanks. Joe
AW: 1.7.1 working copies - verification
Posted by Markus Schaber <m....@3s-software.com>.
Hi, Joe,
Von: Joe.Floeder@sungard.com [mailto:Joe.Floeder@sungard.com]
> How do know I have a 1.7.1 working copy? Can I tell by looking at the working copy on the file system? The older version had .svn directories and the entries file. What does the new working copy look like?
Normally, 1.7 working copies only have .svn directories in the top level of the working copy. (Externals and nested WCs are different cases.) This should be enough for a first-glance 1.7.X vs. 1.0.X-1.6.X disambiguation.
> We are running 1.7.1 and 1.6.17 on two different servers - right now I am not sure I am connecting to the correct svnserve process.
As both the 1.6.X and 1.7.X clients can connect to both 1.6.X and 1.7.X servers, and the server repository format did not change between 1.6.X and 1.7.X, so I'm not sure which problem you want to describe me with that sentence.
Markus
1.7.1 working copies - verification
Posted by Jo...@sungard.com.
How do know I have a 1.7.1 working copy? Can I tell by looking at the working copy on the file system? The older version had .svn directories and the entries file. What does the new working copy look like?
We are running 1.7.1 and 1.6.17 on two different servers - right now I am not sure I am connecting to the correct svnserve process.
Re: Check-in all files at a time?
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
Am 07.11.2011 06:53, schrieb yerra babji:
> Is there any way to mandate svn users to check in all the files they
> modified?
No.
This in and of itself is also not a problem, I would claim. You are
obviously seeing a problem you would like to "fix" with this. If you
told us what that problem is, people could give better advise how to fix it.
Ludovic already mentioned a few things that could help you. Another
thing that could help you is to make people understand why you want them
to do that. If people cause problems by checking in half-consistent
versions, you could isolate them with feature branches. You could (and
that's a good idea anyway) set up an automated build and test run,
either after every checkin or regularly ("nightly build"). If things
fail during a nightly build, call in people next morning and work out
what caused the failure.
Don't try to fix social problems with technical solutions. At best,
technical approaches can help and guide.
Good luck!
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************