Re: Queries about SVN (Security related)
On Tue, Nov 29, 2011 at 7:44 AM, Daniel Shahaf d...@daniel.shahaf.name wrote: Jerryleen S wrote on Tue, Nov 29, 2011 at 10:50:06 +0530: but as per discussion in the thread it isn't possible to differentiate deleting or adding or modifying transaction during pre-commit script. I don't understand what you're claiming. The situation is: - The pre-commit hook knows the EXACT contents of the transaction (which will become a revision if the hook does exit(0)). That in particular includes the equivalent of 'svn log -qv' of the txn. (five minutes on a file:///tmp/r repository with 'svnlook -t' will confirm or refute this) - The pre-commit hook can modify the txn before it becomes a revision. Such modifications cannot be communicated to the client performing the commit. (for the former assertion, see svn_fs_open_txn() and similar FS APIs. for the latter, the client code (libsvn_ra and libsvn_wc) assumes that the changes sent to the server are those committed, and updates the wc state based on the changes sent.) To reiterate what Daniel said: you can perfectly well see the difference between an Add (A), a Delete (D) or a Modification (M) in a pre-commit hook. The command 'svnlook changed -t transaction' will give you a list of everything that's about to be changed by the transaction in question. Lines beginning with A indicate Additions, D for Deletes and M for Modifications. Of course this is only speaking at file/directory granularity (which files/directories are added, deleted, modified). If you want to know if a Modified file has additions, deletions or modifications, you'll have to examine/parse the output of 'svnlook diff' to see the concrete content changes ... -- Johan
Re: branching strategies in subversion
On Tue, Nov 29, 2011 at 2:13 AM, jes Struck j...@praqma.net wrote: Thank you for all youre responses The point uis that im not interested in feature branching, my developers are interested in working with developer branches because its hard for them to setup up eclipse each time they branch of from trunk, (i now the switch command is the solution) , but atm. they are just not branching, so to get them started we will work like they get developer branches and the hope the discover how easy it is and start using branching for features. which i agree is the right thing onles youre in ClearCase UCM. A branch is a branch. There should be absolutely no difference between copying a new branch from the trunk after completing a feature and switching to it, deleting the head of the current branch and copying back to the same name from the trunk, or properly merging the other trunk changes into the branch. Well there is a difference but only in the way you would access old versions of the branch work to find temporary changes that didn't get merged to the trunk. With different branch names (the feature branch approach) you'd go to the branch name containing it. If you delete and recreate the same branch name you need peg revision syntax to go back, which may be harder to remember. But the point is that you have to get the other changes from the trunk into the developer branch one way or another and going in the forward direction they all look the same. Personally I think the 'dirty trunk', 'release branch' approach makes more sense if your development work is fairly close-coupled and everyone wants quick access to each others work when big changes are in progress but it may be hard to think that way if you are used to a system that doesn't resolve conflicts easily. -- Les Mikesell lesmikes...@gmail.com
Re: Unreferenced pristines behavior in 1.7
On Tue, Nov 29, 2011 at 3:00 PM, Joshua McKinnon jmmckin...@gmail.com wrote: Having it happen automatically instead of needing to regularly run svn cleanup is definitely preferable. I've never had to run it in the past except in the event of a problem. (e.g. a command did not complete properly, or something else got borked) Note that the difference is that now your pristines are shared. So if you have files in your working copy that are identical there is only a single pristine. Imagine a checkout of an entire repository, including tags and branches. For all of those files in your tags and branches that would are just duplicates of each other there is only a single pristine version stored now where as before every file had a pristine. I could not find any issue # for this either. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Unreferenced pristines behavior in 1.7
On Tue, Nov 29, 2011 at 3:06 PM, Mark Phippard markp...@gmail.com wrote: Note that the difference is that now your pristines are shared. So if you have files in your working copy that are identical there is only a single pristine. Imagine a checkout of an entire repository, including tags and branches. For all of those files in your tags and branches that would are just duplicates of each other there is only a single pristine version stored now where as before every file had a pristine. Oh the new working copy format is absolutely great. The point is only that the pristine files appear to build up over time, which seems new. Any extra build up is removed with an svn cleanup, but I think a lot of people (like me) will not realize they need to perform that step regularly. I am actually in the process of doing an all-branches checkout right now, to try and take advantage of the consolidation available in the new working copy format. When using SSDs, disk usage matters. I could not find any issue # for this either. If no one else replies within a few days, should I create an issue to track this? -- Joshua
Re: Unreferenced pristines behavior in 1.7
On Tue, 29 Nov 2011 15:57:28 +, Joshua McKinnon wrote: ... Oh the new working copy format is absolutely great. The point is only that the pristine files appear to build up over time, which seems new. They do. For every changed file that comes to exist in the sandbox a new pristine copy will be lying around; after committing twenty versions of a file you have nineteen unreferenced pristines there. ... I am actually in the process of doing an all-branches checkout right now, to try and take advantage of the consolidation available in the new working copy format. Unfortunately the consolidation only affects the pristines; you still have separate copies of identicat files in the working copy. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Unreferenced pristines behavior in 1.7
On Tue, Nov 29, 2011 at 3:57 PM, Joshua McKinnon jmmckin...@gmail.com wrote: On Tue, Nov 29, 2011 at 3:06 PM, Mark Phippard markp...@gmail.com wrote: Note that the difference is that now your pristines are shared. So if you have files in your working copy that are identical there is only a single pristine. Imagine a checkout of an entire repository, including tags and branches. For all of those files in your tags and branches that would are just duplicates of each other there is only a single pristine version stored now where as before every file had a pristine. Oh the new working copy format is absolutely great. The point is only that the pristine files appear to build up over time, which seems new. Any extra build up is removed with an svn cleanup, but I think a lot of people (like me) will not realize they need to perform that step regularly. I am actually in the process of doing an all-branches checkout right now, to try and take advantage of the consolidation available in the new working copy format. When using SSDs, disk usage matters. I could not find any issue # for this either. If no one else replies within a few days, should I create an issue to track this? I filed an issue and updated the release notes: http://subversion.apache.org/docs/release-notes/1.7.html#wc-pristines -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Unreferenced pristines behavior in 1.7
I am actually in the process of doing an all-branches checkout right now, to try and take advantage of the consolidation available in the new working copy format. When using SSDs, disk usage matters. I used to work (pre 1.7) with many branches including the trunk in separate WCs Now I check out the project path with branches and tags being depth empty except for selective checkout and check out the trunk... all nicely in the same WC (and hence shared pristines) without checking everything out. The shared pristines pay off very well here. That said, an 'svn cleanup' recently recovered 200mb and nearly 25000 files so automatic pristine cleanup will be very nice when it arrives. I'd actually like the ability to separate the pristine-store from the WC root since I'd like to have several WCs for the same trunk or branch with various pieces of work-in-progress - sharing pristines there would be great. Maybe something like the Bazaar shared-repositories. Just look up the path until you hit a .svn that contains a pristine-store. .../work/ .svn/ --- contains a pristine store, not a WC. All of the pristines of WCs below. projectX/ default/ .svn/ -- the root for this WC trunk/ ... branches/ -- @ depth empty - only the branches I want checked out. feature-123/ ... feature-456/ ... that-thing-i-am-doing-on-trunk/ -- same trunk as .../work/projectX/default/trunk .svn/ -- the root for this WC that-other-thing-i-am-doing-on-trunk/ -- same trunk as .../work/projectX/default/trunk .svn/ -- the root for this WC I personally think this approach is better than the suggestion of a pristine-store in your profile for the whole machine. Sometimes you do want separation. You can always link the folders off elsewhere. -- Talden
Re: Unreferenced pristines behavior in 1.7
On Tue, Nov 29, 2011 at 6:28 PM, Talden tal...@gmail.com wrote: I'd actually like the ability to separate the pristine-store from the WC root since I'd like to have several WCs for the same trunk or branch with various pieces of work-in-progress - sharing pristines there would be great. Maybe something like the Bazaar shared-repositories. Just look up the path until you hit a .svn that contains a pristine-store. Interesting idea. The top-level .svn folder would need to include the wc.db and the pristines, so maybe the other .svn folders would just be empty with some kind of pointer file. A central pristine store needs a central wc.db to go with it though, or else the ref counting could not work. -- Thanks Mark Phippard http://markphip.blogspot.com/
