RE: Queries about SVN (Security related)
Dear Mark, Thanks for prompt reply, is it possible to give hook script for first 2 queries as I have done exhaustive search in search forums but haven't found hook script to do the following action > 1. Restricting branching activity based on roles specified. >That is denying branch functionality to users based on there roles. > 2. Denying delete/add folder to certain users, it is not just >r or r/w. if user has r/w access but shouldn't have delete or >add access, only modify commit should be accessible. 3rd query > 3. Is it possible host repos in 2 different physical locations? I meant in Collabnet admin GUI we can give location of only one data location, i.e., if we want to place repos in more than one machine or physical location, is it possible. I assume you have found and read the online subversion book? http://svnbook.red-bean.com/en/1.7/index.html Yes I have PDF copy of this file, it is very informative. I have been maintaining SVN since 2 months using this document. Thanks & Regards, Jerryleen S Project Coordinator, PRDC -Original Message- From: Cooke, Mark [mailto:mark.co...@siemens.com] Sent: Friday, November 25, 2011 12:48 PM To: Jerryleen S; users@subversion.apache.org Cc: channaveeraswamy Subject: RE: Queries about SVN (Security related) > -Original Message- > From: Jerryleen S [mailto:jerrylee...@prdcinfotech.com] > Sent: 25 November 2011 06:32 > Subject: Queries about SVN (Security related) > > Dear Sir, > > We are in the process of selecting SVN system in our company, > could you please clarify following points. > > 1. Restricting branching activity based on roles specified. >That is denying branch functionality to users based on there roles. > 2. Denying delete/add folder to certain users, it is not just >r or r/w. if user has r/w access but shouldn't have delete or >add access, only modify commit should be accessible. This functionality is not "baked in". It might well be possible to do with a pre-commit hook but you (your admin team) would need to write and maintain the script. Personally I have not tried to do such things. > 3. Is it possible host repos in 2 different physical locations? What do you mean by host? There is built-in support for providing read-only mirrors (also as write-through proxies) but if you want multiple 'master' repositories then you need to look to WanDISCO's proprietry MultiSite extension. > 4. How to delete folders or file permanently. I assume you mean "remove completely from all history"? Ignoring all the arguments about if a source control product should even allow this, it is only currently possible by 'dump', 'dumpfilter' and 'reload'ing the whole repository. It is a feature on the roadmap (http://subversion.apache.org/roadmap.html) called 'obliterate' but not soon. > As of now we are using following software for svn access: > > Collabnet Subversion Edge 2.0.1 > SVN 1.6 > Tortoise 1.6. > > We are using SVN system as trail basis before adapting for > entire company. So please clarify above issues. I assume you have found and read the online subversion book? http://svnbook.red-bean.com/en/1.7/index.html > Thanks & Regards, > > Jerryleen S > > Project Coordinator, PRDC > > ** > > Please consider the environment before printing this email. > Do it only if it is absolutely necessary. > > DISCLAIMER: > The contents of this email including attachment(s), if any, > are intended for the exclusive use of the addressee(s) and > may contain proprietary, confidential or privileged > information. If you have received this mail in error, please > notify the > sender immediately and destroy all copies of this message and > any attachment(s).Computer viruses or other malware > can be transmitted by email. Therefore, please check this > email and any attachment(s) for the presence of viruses, malware, > etc. The PRDC accepts no liability whatsoever for any damage > - whether direct or consequential - caused by any virus, malware, > etc. transmitted by this email. > ** > > ...can you remove the above disclaimer from posts to public mail lists (it makes no sense)? ~ mark c ** Please consider the environment before printing this email. Do it only if it is absolutely necessary. DISCLAIMER: The contents of this email including attachment(s), if any, are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you have received this mail in error, please notify the sender immediately and destroy all copies of this message and any attachment(s).Comput
RE: Queries about SVN (Security related)
[Please reply in-line, it makes it easier to see the full context...] > -Original Message- > From: Jerryleen S [mailto:jerrylee...@prdcinfotech.com] > Sent: 25 November 2011 09:43 > To: Cooke, Mark; users@subversion.apache.org > Cc: channaveeraswamy > Subject: RE: Queries about SVN (Security related) > > -Original Message- > From: Cooke, Mark [mailto:mark.co...@siemens.com] > Sent: Friday, November 25, 2011 12:48 PM > To: Jerryleen S; users@subversion.apache.org > Cc: channaveeraswamy > Subject: RE: Queries about SVN (Security related) > > > -Original Message- > > From: Jerryleen S [mailto:jerrylee...@prdcinfotech.com] > > Sent: 25 November 2011 06:32 > > Subject: Queries about SVN (Security related) > > > > Dear Sir, > > > > We are in the process of selecting SVN system in our company, > > could you please clarify following points. > > > > 1. Restricting branching activity based on roles specified. > >That is denying branch functionality to users based on > >their roles. > > 2. Denying delete/add folder to certain users, it is not just > >r or r/w. if user has r/w access but shouldn't have delete or > >add access, only modify commit should be accessible. > > This functionality is not "baked in". It might well be > possible to do with a pre-commit hook but you (your admin > team) would need to write and maintain the script. > Personally I have not tried to do such things. > > Dear Mark, > > Thanks for prompt reply, is it possible to give hook script > for first 2 queries as I have done exhaustive search in > search forums but haven't found hook script to do the following action Sorry, I have no experience in doing this having only done a few simple post-commit hooks on windows. I too find it difficult to find good hook examples, especially for windoze. Have you looked at the default pre-commit.tmpl that is installed in your hooks directory? That shows how to get the author name and references a perl script to do some authorisation checking... > > > 3. Is it possible host repos in 2 different physical locations? > > > > What do you mean by host? There is built-in support for > > providing read-only mirrors (also as write-through proxies) > > but if you want multiple 'master' repositories then you need > > to look to WanDISCO's proprietry MultiSite extension. > > > I meant in Collabnet admin GUI we can give location of only > one data location, i.e., if we want to place repos in more > than one machine or physical location, is it possible. > Do you mean separate repositories? That is down to how you configure apache. I have not used the Collabnet admin GUI having decided at the start that I wanted to understand what was going on. You can easily declare multiple SVNParentPath locations (I do this for hosting separate groups of projects) within the one apache config. However, AFAIK you need the data files on storage "local" to the server (networked storage does not seem to be recommended). I use a virtualised windoze server box with virtual local disk space but we have modest storage requirements so far. To use a separate server I would assume you need to setup apache & subversion on that server too... ~ mark c > > 4. How to delete folders or file permanently. > > I assume you mean "remove completely from all history"? > Ignoring all the arguments about if a source control product > should even allow this, it is only currently possible by > 'dump', 'dumpfilter' and 'reload'ing the whole repository. > It is a feature on the roadmap > (http://subversion.apache.org/roadmap.html) called > 'obliterate' but not soon. > > > As of now we are using following software for svn access: > > > > Collabnet Subversion Edge 2.0.1 > > SVN 1.6 > > Tortoise 1.6. > > > > We are using SVN system as trail basis before adapting for > > entire company. So please clarify above issues. > > I assume you have found and read the online subversion book? > > http://svnbook.red-bean.com/en/1.7/index.html > Yes I have PDF copy of this file, it is very informative. I > have been maintaining SVN since 2 months using this document. > > Thanks & Regards, > > Jerryleen S > > Project Coordinator, PRDC >
Re: BDB backend in SVN 1.7.1
> Old BDB-backed repositories stored the older revision as fulltext and > newer revisions as deltas. Really? Here is a quotation from SVN 1.4.6 libsvn_fs_base/note/structure: "At present, Subversion generally stores the youngest strings in "fulltext" form, and older strings as "delta"s against them (unless the delta would save no space compared to the fulltext). " My own experiments with SVN 1.4 code confirm that. > Repositories created with or 'svnadmin > upgrade'd by 1.6 and newer reverse this for new revisions of files > (while making sure not to introduce a dependency loop in the direction > of deltas). > > http://subversion.apache.org/docs/release-notes/1.6#bdb-forward-deltas > > On Friday, November 25, 2011 1:08 AM, "Vyacheslav Zholudev" > wrote: >> Hi, >> >> how does SVN 1.7.1 store fulltext and deltas in the BDB backend? From some >> time ago I remember that previous versions of SVN stored "almost" always a >> HEAD revision as fulltext, and others as reverse deltas.(except the case >> when a delta is bigger that fulltext) Was this behavior changed in SVN 1.7? >> I've looked at the notes about BDB and they don't differ almost at all from >> SVN 1.4's ones. Of course, I could look into the code more carefully, but my >> hope was that it wouldn't be a big deal to give me a short answer, if >> possible. >> >> Thanks in advance! >> >> Best, >> Vyacheslav >> >> >>
Re: BDB backend in SVN 1.7.1
Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 11:13:00 +0100: > > > Old BDB-backed repositories stored the older revision as fulltext and > > newer revisions as deltas. > > Really? It seems that I should have swapped "older" and "newer" in the quoted sentence. Thanks for catching that. > Here is a quotation from SVN 1.4.6 libsvn_fs_base/note/structure: > "At present, Subversion generally stores > the youngest strings in "fulltext" form, and older strings as "delta"s > against them (unless the delta would save no space compared to the > fulltext). > " > My own experiments with SVN 1.4 code confirm that. > > > > > Repositories created with or 'svnadmin > > upgrade'd by 1.6 and newer reverse this for new revisions of files > > (while making sure not to introduce a dependency loop in the direction > > of deltas). > > > > http://subversion.apache.org/docs/release-notes/1.6#bdb-forward-deltas > > > > On Friday, November 25, 2011 1:08 AM, "Vyacheslav Zholudev" > > wrote: > >> Hi, > >> > >> how does SVN 1.7.1 store fulltext and deltas in the BDB backend? From some > >> time ago I remember that previous versions of SVN stored "almost" always a > >> HEAD revision as fulltext, and others as reverse deltas.(except the case > >> when a delta is bigger that fulltext) Was this behavior changed in SVN > >> 1.7? I've looked at the notes about BDB and they don't differ almost at > >> all from SVN 1.4's ones. Of course, I could look into the code more > >> carefully, but my hope was that it wouldn't be a big deal to give me a > >> short answer, if possible. > >> > >> Thanks in advance! > >> > >> Best, > >> Vyacheslav > >> > >> > >> >
Re: BDB backend in SVN 1.7.1
Hi Daniel, would it be easy to change the code (I want to do it for my experiments) so that the HEAD (youngest) revisions are stored as fulltexts? Or is it something that was not foreseen by design to easily switch between approaches of representing history information? Thanks, Vyacheslav On Nov 25, 2011, at 11:59 AM, Daniel Shahaf wrote: > Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 11:13:00 +0100: >> >>> Old BDB-backed repositories stored the older revision as fulltext and >>> newer revisions as deltas. >> >> Really? > > It seems that I should have swapped "older" and "newer" in the quoted > sentence. Thanks for catching that. > >> Here is a quotation from SVN 1.4.6 libsvn_fs_base/note/structure: >> "At present, Subversion generally stores >> the youngest strings in "fulltext" form, and older strings as "delta"s >> against them (unless the delta would save no space compared to the >> fulltext). >> " >> My own experiments with SVN 1.4 code confirm that. >> >> >> >>> Repositories created with or 'svnadmin >>> upgrade'd by 1.6 and newer reverse this for new revisions of files >>> (while making sure not to introduce a dependency loop in the direction >>> of deltas). >>> >>> http://subversion.apache.org/docs/release-notes/1.6#bdb-forward-deltas >>> >>> On Friday, November 25, 2011 1:08 AM, "Vyacheslav Zholudev" >>> wrote: Hi, how does SVN 1.7.1 store fulltext and deltas in the BDB backend? From some time ago I remember that previous versions of SVN stored "almost" always a HEAD revision as fulltext, and others as reverse deltas.(except the case when a delta is bigger that fulltext) Was this behavior changed in SVN 1.7? I've looked at the notes about BDB and they don't differ almost at all from SVN 1.4's ones. Of course, I could look into the code more carefully, but my hope was that it wouldn't be a big deal to give me a short answer, if possible. Thanks in advance! Best, Vyacheslav >>
Re: BDB backend in SVN 1.7.1
Change SVN_FS_BASE__MIN_FORWARD_DELTAS_FORMAT to be larger than SVN_FS_BASE__FORMAT_NUMBER. Whether repositories created by an svn patched in this way will be interoperable with repositories created by an unpatched svn is LAAEFTR'd. I'd be cautious and change db/fs-type or db/format. Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 12:04:22 +0100: > Hi Daniel, > > would it be easy to change the code (I want to do it for my experiments) so > that the HEAD (youngest) revisions are stored as fulltexts? Or is it > something that was not foreseen by design to easily switch between approaches > of representing history information? > > Thanks, > Vyacheslav > > On Nov 25, 2011, at 11:59 AM, Daniel Shahaf wrote: > > > Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 11:13:00 +0100: > >> > >>> Old BDB-backed repositories stored the older revision as fulltext and > >>> newer revisions as deltas. > >> > >> Really? > > > > It seems that I should have swapped "older" and "newer" in the quoted > > sentence. Thanks for catching that. > > > >> Here is a quotation from SVN 1.4.6 libsvn_fs_base/note/structure: > >> "At present, Subversion generally stores > >> the youngest strings in "fulltext" form, and older strings as "delta"s > >> against them (unless the delta would save no space compared to the > >> fulltext). > >> " > >> My own experiments with SVN 1.4 code confirm that. > >> > >> > >> > >>> Repositories created with or 'svnadmin > >>> upgrade'd by 1.6 and newer reverse this for new revisions of files > >>> (while making sure not to introduce a dependency loop in the direction > >>> of deltas). > >>> > >>> http://subversion.apache.org/docs/release-notes/1.6#bdb-forward-deltas > >>> > >>> On Friday, November 25, 2011 1:08 AM, "Vyacheslav Zholudev" > >>> wrote: > Hi, > > how does SVN 1.7.1 store fulltext and deltas in the BDB backend? From > some time ago I remember that previous versions of SVN stored "almost" > always a HEAD revision as fulltext, and others as reverse deltas.(except > the case when a delta is bigger that fulltext) Was this behavior changed > in SVN 1.7? I've looked at the notes about BDB and they don't differ > almost at all from SVN 1.4's ones. Of course, I could look into the code > more carefully, but my hope was that it wouldn't be a big deal to give > me a short answer, if possible. > > Thanks in advance! > > Best, > Vyacheslav > > > > >> >
Re: BDB backend in SVN 1.7.1
Thanks, Daniel. That's the pointer I needed. However, I didn't understand what LAAEFTR means. Vyacheslav On Nov 25, 2011, at 12:17 PM, Daniel Shahaf wrote: > Change SVN_FS_BASE__MIN_FORWARD_DELTAS_FORMAT to be larger than > SVN_FS_BASE__FORMAT_NUMBER. > > Whether repositories created by an svn patched in this way will be > interoperable with repositories created by an unpatched svn is > LAAEFTR'd. I'd be cautious and change db/fs-type or db/format. > > Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 12:04:22 +0100: >> Hi Daniel, >> >> would it be easy to change the code (I want to do it for my experiments) so >> that the HEAD (youngest) revisions are stored as fulltexts? Or is it >> something that was not foreseen by design to easily switch between >> approaches of representing history information? >> >> Thanks, >> Vyacheslav >> >> On Nov 25, 2011, at 11:59 AM, Daniel Shahaf wrote: >> >>> Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 11:13:00 +0100: > Old BDB-backed repositories stored the older revision as fulltext and > newer revisions as deltas. Really? >>> >>> It seems that I should have swapped "older" and "newer" in the quoted >>> sentence. Thanks for catching that. >>> Here is a quotation from SVN 1.4.6 libsvn_fs_base/note/structure: "At present, Subversion generally stores the youngest strings in "fulltext" form, and older strings as "delta"s against them (unless the delta would save no space compared to the fulltext). " My own experiments with SVN 1.4 code confirm that. > Repositories created with or 'svnadmin > upgrade'd by 1.6 and newer reverse this for new revisions of files > (while making sure not to introduce a dependency loop in the direction > of deltas). > > http://subversion.apache.org/docs/release-notes/1.6#bdb-forward-deltas > > On Friday, November 25, 2011 1:08 AM, "Vyacheslav Zholudev" > wrote: >> Hi, >> >> how does SVN 1.7.1 store fulltext and deltas in the BDB backend? From >> some time ago I remember that previous versions of SVN stored "almost" >> always a HEAD revision as fulltext, and others as reverse deltas.(except >> the case when a delta is bigger that fulltext) Was this behavior changed >> in SVN 1.7? I've looked at the notes about BDB and they don't differ >> almost at all from SVN 1.4's ones. Of course, I could look into the code >> more carefully, but my hope was that it wouldn't be a big deal to give >> me a short answer, if possible. >> >> Thanks in advance! >> >> Best, >> Vyacheslav >> >> >> >>
Re: BDB backend in SVN 1.7.1
"left as an exercise for the reader" --- in other words, I was identifying a potential issue and letting the audience figure out the solution for themselves. It's a standard idiom in math textbooks... (and, of course, if you have questions about that interoperability issue, feel free to raise them on this list.) Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 13:07:52 +0100: > Thanks, Daniel. That's the pointer I needed. > However, I didn't understand what LAAEFTR means. > > Vyacheslav > > > On Nov 25, 2011, at 12:17 PM, Daniel Shahaf wrote: > > > Change SVN_FS_BASE__MIN_FORWARD_DELTAS_FORMAT to be larger than > > SVN_FS_BASE__FORMAT_NUMBER. > > > > Whether repositories created by an svn patched in this way will be > > interoperable with repositories created by an unpatched svn is > > LAAEFTR'd. I'd be cautious and change db/fs-type or db/format. > > > > Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 12:04:22 +0100: > >> Hi Daniel, > >> > >> would it be easy to change the code (I want to do it for my experiments) > >> so that the HEAD (youngest) revisions are stored as fulltexts? Or is it > >> something that was not foreseen by design to easily switch between > >> approaches of representing history information? > >> > >> Thanks, > >> Vyacheslav > >> > >> On Nov 25, 2011, at 11:59 AM, Daniel Shahaf wrote: > >> > >>> Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 11:13:00 +0100: > > > Old BDB-backed repositories stored the older revision as fulltext and > > newer revisions as deltas. > > Really? > >>> > >>> It seems that I should have swapped "older" and "newer" in the quoted > >>> sentence. Thanks for catching that. > >>> > Here is a quotation from SVN 1.4.6 libsvn_fs_base/note/structure: > "At present, Subversion generally stores > the youngest strings in "fulltext" form, and older strings as "delta"s > against them (unless the delta would save no space compared to the > fulltext). > " > My own experiments with SVN 1.4 code confirm that. > > > > > Repositories created with or 'svnadmin > > upgrade'd by 1.6 and newer reverse this for new revisions of files > > (while making sure not to introduce a dependency loop in the direction > > of deltas). > > > > http://subversion.apache.org/docs/release-notes/1.6#bdb-forward-deltas > > > > On Friday, November 25, 2011 1:08 AM, "Vyacheslav Zholudev" > > wrote: > >> Hi, > >> > >> how does SVN 1.7.1 store fulltext and deltas in the BDB backend? From > >> some time ago I remember that previous versions of SVN stored "almost" > >> always a HEAD revision as fulltext, and others as reverse > >> deltas.(except the case when a delta is bigger that fulltext) Was this > >> behavior changed in SVN 1.7? I've looked at the notes about BDB and > >> they don't differ almost at all from SVN 1.4's ones. Of course, I > >> could look into the code more carefully, but my hope was that it > >> wouldn't be a big deal to give me a short answer, if possible. > >> > >> Thanks in advance! > >> > >> Best, > >> Vyacheslav > >> > >> > >> > > >> >
Re: BDB backend in SVN 1.7.1
Thanks, I studied math not in English, that's why I didn't know :) I made a simple tests and it seems to work nicely. However, I'm not sure whether it will work with more complicated cases like copying, deleting, etc. Vyacheslav On Nov 25, 2011, at 1:15 PM, Daniel Shahaf wrote: > "left as an exercise for the reader" --- in other words, I was > identifying a potential issue and letting the audience figure out the > solution for themselves. It's a standard idiom in math textbooks... > > (and, of course, if you have questions about that interoperability > issue, feel free to raise them on this list.) > > Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 13:07:52 +0100: >> Thanks, Daniel. That's the pointer I needed. >> However, I didn't understand what LAAEFTR means. >> >> Vyacheslav >> >> >> On Nov 25, 2011, at 12:17 PM, Daniel Shahaf wrote: >> >>> Change SVN_FS_BASE__MIN_FORWARD_DELTAS_FORMAT to be larger than >>> SVN_FS_BASE__FORMAT_NUMBER. >>> >>> Whether repositories created by an svn patched in this way will be >>> interoperable with repositories created by an unpatched svn is >>> LAAEFTR'd. I'd be cautious and change db/fs-type or db/format. >>> >>> Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 12:04:22 +0100: Hi Daniel, would it be easy to change the code (I want to do it for my experiments) so that the HEAD (youngest) revisions are stored as fulltexts? Or is it something that was not foreseen by design to easily switch between approaches of representing history information? Thanks, Vyacheslav On Nov 25, 2011, at 11:59 AM, Daniel Shahaf wrote: > Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 11:13:00 +0100: >> >>> Old BDB-backed repositories stored the older revision as fulltext and >>> newer revisions as deltas. >> >> Really? > > It seems that I should have swapped "older" and "newer" in the quoted > sentence. Thanks for catching that. > >> Here is a quotation from SVN 1.4.6 libsvn_fs_base/note/structure: >> "At present, Subversion generally stores >> the youngest strings in "fulltext" form, and older strings as "delta"s >> against them (unless the delta would save no space compared to the >> fulltext). >> " >> My own experiments with SVN 1.4 code confirm that. >> >> >> >>> Repositories created with or 'svnadmin >>> upgrade'd by 1.6 and newer reverse this for new revisions of files >>> (while making sure not to introduce a dependency loop in the direction >>> of deltas). >>> >>> http://subversion.apache.org/docs/release-notes/1.6#bdb-forward-deltas >>> >>> On Friday, November 25, 2011 1:08 AM, "Vyacheslav Zholudev" >>> wrote: Hi, how does SVN 1.7.1 store fulltext and deltas in the BDB backend? From some time ago I remember that previous versions of SVN stored "almost" always a HEAD revision as fulltext, and others as reverse deltas.(except the case when a delta is bigger that fulltext) Was this behavior changed in SVN 1.7? I've looked at the notes about BDB and they don't differ almost at all from SVN 1.4's ones. Of course, I could look into the code more carefully, but my hope was that it wouldn't be a big deal to give me a short answer, if possible. Thanks in advance! Best, Vyacheslav >> >>
Re: BDB backend in SVN 1.7.1
To clarify, the issues I was concerned about weren't with tree changes (the level of the code dealing with content reps isn't aware of those), but with creating/accessing a single repository sometimes via unmodified svn 1.7.1 libraries and sometimes via forward-delta-patched libraries. The part I left to the readers was determining whther or not Badness will happen in the event of such "mixed" access. Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 13:20:55 +0100: > Thanks, I studied math not in English, that's why I didn't know :) > > I made a simple tests and it seems to work nicely. However, I'm not sure > whether it will work with more complicated cases like copying, deleting, etc. > > > Vyacheslav > > On Nov 25, 2011, at 1:15 PM, Daniel Shahaf wrote: > > > "left as an exercise for the reader" --- in other words, I was > > identifying a potential issue and letting the audience figure out the > > solution for themselves. It's a standard idiom in math textbooks... > > > > (and, of course, if you have questions about that interoperability > > issue, feel free to raise them on this list.) > > > > Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 13:07:52 +0100: > >> Thanks, Daniel. That's the pointer I needed. > >> However, I didn't understand what LAAEFTR means. > >> > >> Vyacheslav > >> > >> > >> On Nov 25, 2011, at 12:17 PM, Daniel Shahaf wrote: > >> > >>> Change SVN_FS_BASE__MIN_FORWARD_DELTAS_FORMAT to be larger than > >>> SVN_FS_BASE__FORMAT_NUMBER. > >>> > >>> Whether repositories created by an svn patched in this way will be > >>> interoperable with repositories created by an unpatched svn is > >>> LAAEFTR'd. I'd be cautious and change db/fs-type or db/format. > >>> > >>> Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 12:04:22 +0100: > Hi Daniel, > > would it be easy to change the code (I want to do it for my experiments) > so that the HEAD (youngest) revisions are stored as fulltexts? Or is it > something that was not foreseen by design to easily switch between > approaches of representing history information? > > Thanks, > Vyacheslav > > On Nov 25, 2011, at 11:59 AM, Daniel Shahaf wrote: > > > Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 11:13:00 +0100: > >> > >>> Old BDB-backed repositories stored the older revision as fulltext and > >>> newer revisions as deltas. > >> > >> Really? > > > > It seems that I should have swapped "older" and "newer" in the quoted > > sentence. Thanks for catching that. > > > >> Here is a quotation from SVN 1.4.6 libsvn_fs_base/note/structure: > >> "At present, Subversion generally stores > >> the youngest strings in "fulltext" form, and older strings as "delta"s > >> against them (unless the delta would save no space compared to the > >> fulltext). > >> " > >> My own experiments with SVN 1.4 code confirm that. > >> > >> > >> > >>> Repositories created with or 'svnadmin > >>> upgrade'd by 1.6 and newer reverse this for new revisions of files > >>> (while making sure not to introduce a dependency loop in the direction > >>> of deltas). > >>> > >>> http://subversion.apache.org/docs/release-notes/1.6#bdb-forward-deltas > >>> > >>> On Friday, November 25, 2011 1:08 AM, "Vyacheslav Zholudev" > >>> wrote: > Hi, > > how does SVN 1.7.1 store fulltext and deltas in the BDB backend? > From some time ago I remember that previous versions of SVN stored > "almost" always a HEAD revision as fulltext, and others as reverse > deltas.(except the case when a delta is bigger that fulltext) Was > this behavior changed in SVN 1.7? I've looked at the notes about BDB > and they don't differ almost at all from SVN 1.4's ones. Of course, > I could look into the code more carefully, but my hope was that it > wouldn't be a big deal to give me a short answer, if possible. > > Thanks in advance! > > Best, > Vyacheslav > > > > >> > > >> >
Re: BDB backend in SVN 1.7.1
I guess "badness" can happen only when accessing repositories locally (not via svn:// or http(s)://) with patched and not patched SVN. But usually only one version of SVN is installed on the server side, so that should not be a big problem. However, it's a nice exercise to check. Vyacheslav On Nov 25, 2011, at 1:29 PM, Daniel Shahaf wrote: > To clarify, the issues I was concerned about weren't with tree changes > (the level of the code dealing with content reps isn't aware of those), > but with creating/accessing a single repository sometimes via > unmodified svn 1.7.1 libraries and sometimes via forward-delta-patched > libraries. > > The part I left to the readers was determining whther or not Badness > will happen in the event of such "mixed" access. > > Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 13:20:55 +0100: >> Thanks, I studied math not in English, that's why I didn't know :) >> >> I made a simple tests and it seems to work nicely. However, I'm not sure >> whether it will work with more complicated cases like copying, deleting, etc. >> >> >> Vyacheslav >> >> On Nov 25, 2011, at 1:15 PM, Daniel Shahaf wrote: >> >>> "left as an exercise for the reader" --- in other words, I was >>> identifying a potential issue and letting the audience figure out the >>> solution for themselves. It's a standard idiom in math textbooks... >>> >>> (and, of course, if you have questions about that interoperability >>> issue, feel free to raise them on this list.) >>> >>> Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 13:07:52 +0100: Thanks, Daniel. That's the pointer I needed. However, I didn't understand what LAAEFTR means. Vyacheslav On Nov 25, 2011, at 12:17 PM, Daniel Shahaf wrote: > Change SVN_FS_BASE__MIN_FORWARD_DELTAS_FORMAT to be larger than > SVN_FS_BASE__FORMAT_NUMBER. > > Whether repositories created by an svn patched in this way will be > interoperable with repositories created by an unpatched svn is > LAAEFTR'd. I'd be cautious and change db/fs-type or db/format. > > Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 12:04:22 +0100: >> Hi Daniel, >> >> would it be easy to change the code (I want to do it for my experiments) >> so that the HEAD (youngest) revisions are stored as fulltexts? Or is it >> something that was not foreseen by design to easily switch between >> approaches of representing history information? >> >> Thanks, >> Vyacheslav >> >> On Nov 25, 2011, at 11:59 AM, Daniel Shahaf wrote: >> >>> Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 11:13:00 +0100: > Old BDB-backed repositories stored the older revision as fulltext and > newer revisions as deltas. Really? >>> >>> It seems that I should have swapped "older" and "newer" in the quoted >>> sentence. Thanks for catching that. >>> Here is a quotation from SVN 1.4.6 libsvn_fs_base/note/structure: "At present, Subversion generally stores the youngest strings in "fulltext" form, and older strings as "delta"s against them (unless the delta would save no space compared to the fulltext). " My own experiments with SVN 1.4 code confirm that. > Repositories created with or 'svnadmin > upgrade'd by 1.6 and newer reverse this for new revisions of files > (while making sure not to introduce a dependency loop in the direction > of deltas). > > http://subversion.apache.org/docs/release-notes/1.6#bdb-forward-deltas > > On Friday, November 25, 2011 1:08 AM, "Vyacheslav Zholudev" > wrote: >> Hi, >> >> how does SVN 1.7.1 store fulltext and deltas in the BDB backend? >> From some time ago I remember that previous versions of SVN stored >> "almost" always a HEAD revision as fulltext, and others as reverse >> deltas.(except the case when a delta is bigger that fulltext) Was >> this behavior changed in SVN 1.7? I've looked at the notes about BDB >> and they don't differ almost at all from SVN 1.4's ones. Of course, >> I could look into the code more carefully, but my hope was that it >> wouldn't be a big deal to give me a short answer, if possible. >> >> Thanks in advance! >> >> Best, >> Vyacheslav >> >> >> >> >>
Re: BDB backend in SVN 1.7.1
On Fri, Nov 25, 2011 at 01:38:44PM +0100, Vyacheslav Zholudev wrote: > I guess "badness" can happen only when accessing repositories locally (not > via svn:// or http(s)://) with patched and not patched SVN. > But usually only one version of SVN is installed on the server side, so that > should not be a big problem. > > However, it's a nice exercise to check. Out of curiosity, what is the reason for this entire exercise? Is it purely academic or is there a use case where storing the HEAD revision as full-text is critical?
Re: BDB backend in SVN 1.7.1
On Nov 25, 2011, at 2:02 PM, Stefan Sperling wrote: > On Fri, Nov 25, 2011 at 01:38:44PM +0100, Vyacheslav Zholudev wrote: >> I guess "badness" can happen only when accessing repositories locally (not >> via svn:// or http(s)://) with patched and not patched SVN. >> But usually only one version of SVN is installed on the server side, so that >> should not be a big problem. >> >> However, it's a nice exercise to check. > > Out of curiosity, what is the reason for this entire exercise? > Is it purely academic or is there a use case where storing the HEAD > revision as full-text is critical? The reason for this is that I had a project based on SVN 1.4 which stored HEAD revisions of XML files in Berkeley DB XML - a native XML database-, instead of BDB. (reverted deltas as well as "normal" files kept on living in BDB). In this way I could also query HEAD XML files directly from SVN repository and access them via BDB XML API - thus it was a nice combination of SVN and XML-database. Recently I've ported my project to SVN 1.7 and due to forward deltas it didn't work as before -- only old revisions of XML files were in BDB XML. But now I changed SVN_FS_BASE__MIN_FORWARD_DELTAS_FORMAT to a higher number, and my project works again as expected. Vyacheslav
Re: Queries about SVN (Security related)
On Fri, Nov 25, 2011 at 3:57 AM, Cooke, Mark wrote: > [Please reply in-line, it makes it easier to see the full context...] >> > Dear Sir, >> > >> > We are in the process of selecting SVN system in our company, >> > could you please clarify following points. >> > >> > 1. Restricting branching activity based on roles specified. >> > That is denying branch functionality to users based on >> > their roles. >> > 2. Denying delete/add folder to certain users, it is not just >> > r or r/w. if user has r/w access but shouldn't have delete or >> > add access, only modify commit should be accessible. >> >> This functionality is not "baked in". It might well be >> possible to do with a pre-commit hook but you (your admin >> team) would need to write and maintain the script. >> Personally I have not tried to do such things. Amen. Pre-commit scripting is extremely powerful and flexible, because it supports whatever a scripting language can do. But let's be clear. If they have "modify" access, they have "delete" access, at least with the scripting and authorization structures I've seen. "Create" access is a bit different: there are setups that allow creating tags, for example, but not deleting them. You also want to think very hard about what kind of access you provide, and what kind of layout you use. Apache access allows access control through normal Apache configurations, which can be quite sophisticated, but presents the old (and much lamented by me) problem that the UNIX and Linux Subversion clients store their passwords in clear text, by default, for http:// or https:// access. It's why I insiste on svn+ssh access, and that has different tools for controlling access based on the svnserve configuration. Workflow will also matter tomake it usable. Will people work in one large repository with lots of branches and distinct projects, each with their own branches and trunks and tags? This is common, and may be easier to manage, but means one authorization and access setup to manage and to screw up. If it's chaning all the time, it's easy to cut off *everyone's* access with one typo, and there aren't currently GUI's or sophisticated editing tools for managing this, so use caution before getting too cute. >> > > 3. Is it possible host repos in 2 different physical locations? >> > >> > What do you mean by host? There is built-in support for >> > providing read-only mirrors (also as write-through proxies) >> > but if you want multiple 'master' repositories then you need >> > to look to WanDISCO's proprietry MultiSite extension. >> > >> I meant in Collabnet admin GUI we can give location of only >> one data location, i.e., if we want to place repos in more >> than one machine or physical location, is it possible. >> > Do you mean separate repositories? That is down to how you configure apache. > I have not used the Collabnet admin GUI having decided at the start that I > wanted to understand what was going on. You can easily declare multiple > SVNParentPath locations (I do this for hosting separate groups of projects) > within the one apache config. However, AFAIK you need the data files on > storage "local" to the server (networked storage does not seem to be > recommended). I use a virtualised windoze server box with virtual local disk > space but we have modest storage requirements so far. There's also the more sophisticated tools of WanDisco's commercial grade "multi-home" setup, designed to keep multiple repositories synchronized and available for failover behavior. Interesting stuff that I've not had the money and personal requirement for, but it might serve for this. >> > 4. How to delete folders or file permanently. >> >> I assume you mean "remove completely from all history"? >> Ignoring all the arguments about if a source control product >> should even allow this, it is only currently possible by >> 'dump', 'dumpfilter' and 'reload'ing the whole repository. >> It is a feature on the roadmap >> (http://subversion.apache.org/roadmap.html) called >> 'obliterate' but not soon. Yes, "obliterate". Its absence is a long-standing problem: Once someone stores an inappropriate and bulky DVD image, or a file with confidential information in it, it's an extremely awkward and fragile and manual process to remove it. The easiest way is usually to transfer the data to a new repository with the old data excluded, and switch everyone to use the new repository. This can cause real problems with ongoing work, but it works. Note that the idea that a source control should *never* eliminate all traces of its history is understandable. It used to be too easy to completely screw up a CVS repository with a casual deletion of a particular file, and Subversion is sometimes referred to as "CVS done right", so the historical resistance to such a feature is understandable. It's very dangerous and could delete exactly the change history you need badly to figure out when something got screwed up and by who
getting revision number into text file inside the working copy folder
Dear subversion users, I am trying to automatically get the actual revision number of my subversion repository into a text file inside the subversion project. More precisely, I am using subversion to keep track of the changes I do to the code of several R packages. These packages contain a file named "DESCRIPTION" containig (amongst other) the following line: Version: 0.5.0.1 When I "build" these packages into *tar.gz R packages (by running R CMD build ... ) this version number is automatically used as the number for that R package and can be accessed easily from within R by running sessionInfo() after loading this package. Now I would like to have the last digit (1 in this case) to resemble my subversion revision number to get a direct reference from within R to the version of the code that was used to compile the package. I did the following: 1. run the following in the folder where DESCRIPTION is: svn propset svn:keywords "LastChangedRevision" DESCRIPTION 2. And changed the relevant line in DESCRIPTION to: Version: 0.5.0.$LastChangedRevision$ This works partially but changes the line in DESCRIPTION to (for example): Version: 0.5.0.$LastChangedRevision: 28 $ I need, however: Version: 0.5.0.28 Is there any way to achieve this? In case you have any solution, try to post it understandable to a SVN-newbi :-). Thanks for your help! Jannis
svn patch seems to mangle some properties, specifically svn:eol-style
I just encountered a possible issue with the new 'svn patch' command in Subversion 1.7.1 (r1186859). When the patchfile includes svn:eol-style property changes, they do not seem to get applied properly. An example patchfile is attached. It was generated by doing the following in some random svn working copy: $ echo foo > foo $ svn add foo A foo $ svn ps svn:eol-style native foo property 'svn:eol-style' set on 'foo' $ svn diff foo > foo.diff The foo.diff file now has the following fragment at the end: Added: svn:eol-style ## -0,0 +1 ## +native When you apply this patch to another working copy (or if you revert the file, then apply the patch), the svn:eol-style property gets an extraneous newline added, and svn diff subsequently prints an error about it: $ svn revert foo Reverted 'foo' $ rm foo $ svn patch foo.diff A foo $ svn pg svn:eol-style foo native $ svn diff foo svn: E135001: Unrecognized line ending style When you add arbitrary properties to a file, produce a diff, and use it with 'svn patch', it look like those properties get an added newline: $ echo bar > bar $ svn add bar A bar $ svn ps testprop1 testval1 bar property 'testprop1' set on 'bar' $ svn ps testprop2 testval2 bar property 'testprop2' set on 'bar' $ svn pg testprop1 bar testval1 $ svn pg testprop2 bar testval2 $ svn diff bar > bar.diff $ svn revert bar Reverted 'bar' $ rm bar $ svn patch bar.diff A bar $ svn pg testprop1 bar testval1 $ svn pg testprop2 bar testval2 $ svn diff bar Index: bar === --- bar (revision 0) +++ bar (working copy) @@ -0,0 +1 @@ +bar Property changes on: bar ___ Added: testprop1 ## -0,0 +1 ## +testval1 Added: testprop2 ## -0,0 +1 ## +testval2 Any idea if I'm doing something wrong here? If it seems like a bug, I'd like to file a PR. Index: foo === --- foo (revision 0) +++ foo (working copy) @@ -0,0 +1 @@ +foo Property changes on: foo ___ Added: svn:eol-style ## -0,0 +1 ## +native
line 94: assertion failed (svn_uri_is_canonical(url, pool)) - v1.7.1
--- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\subversion\libsvn_client\checkout.c' line 94: assertion failed (svn_uri_is_canonical(url, pool)) --- OK --- --- Server = latest 1.6 version With checkout from tortoisesvn: using x.x.com: instead of svn://x.x.com: i use: Subversion 1.7.1
Re: getting revision number into text file inside the working copy folder
On Nov 25, 2011, at 10:06, Jannis wrote: > 2. And changed the relevant line in DESCRIPTION to: > > Version: 0.5.0.$LastChangedRevision$ > > > This works partially but changes the line in DESCRIPTION to (for example): > > Version: 0.5.0.$LastChangedRevision: 28 $ > > I need, however: > > Version: 0.5.0.28 > > > Is there any way to achieve this? In case you have any solution, try to post > it understandable to a SVN-newbi :-). Write a script that runs at build time that generates the DESCRIPTION file, possibly from a template. See also: http://subversion.apache.org/faq.html#version-value-in-source
Re: getting revision number into text file inside the working copy folder
On Fri, Nov 25, 2011 at 2:38 PM, Ryan Schmidt wrote: > On Nov 25, 2011, at 10:06, Jannis wrote: > >> 2. And changed the relevant line in DESCRIPTION to: >> >> Version: 0.5.0.$LastChangedRevision$ >> >> >> This works partially but changes the line in DESCRIPTION to (for example): >> >> Version: 0.5.0.$LastChangedRevision: 28 $ >> >> I need, however: >> >> Version: 0.5.0.28 >> >> >> Is there any way to achieve this? In case you have any solution, try to post >> it understandable to a SVN-newbi :-). > > Write a script that runs at build time that generates the DESCRIPTION file, > possibly from a template. > > See also: > > http://subversion.apache.org/faq.html#version-value-in-source I updated something like this, based on the older RPM package building for Subversion, and which I submitted as part of new packaging 1.7.1, it's in the archives at http://comments.gmane.org/gmane.comp.version-control.subversion.devel/132223
Re: svn patch seems to mangle some properties, specifically svn:eol-style
Looks like it's a known issue, see 3430 @XFail() 3431 @Issue(3814) 3432 def patch_set_prop_no_eol(sbox): 3433 "patch doesn't append newline to properties" 3618 @XFail() 3619 @Issue(3991) 3620 def patch_lacking_trailing_eol(sbox): 3621 "patch file lacking trailing eol" which are currently the only XFail tests in patch_tests.py. :) https://svn.apache.org/repos/asf/subversion/trunk/subversion/tests/cmdline/patch_tests.py Dimitry Andric wrote on Fri, Nov 25, 2011 at 18:58:23 +0100: > I just encountered a possible issue with the new 'svn patch' command in > Subversion 1.7.1 (r1186859). When the patchfile includes svn:eol-style > property changes, they do not seem to get applied properly. > > An example patchfile is attached. It was generated by doing the > following in some random svn working copy: > > $ echo foo > foo > $ svn add foo > A foo > $ svn ps svn:eol-style native foo > property 'svn:eol-style' set on 'foo' > $ svn diff foo > foo.diff > > The foo.diff file now has the following fragment at the end: > > Added: svn:eol-style > ## -0,0 +1 ## > +native > > When you apply this patch to another working copy (or if you revert the > file, then apply the patch), the svn:eol-style property gets an > extraneous newline added, and svn diff subsequently prints an error > about it: > > $ svn revert foo > Reverted 'foo' > $ rm foo > $ svn patch foo.diff > A foo > $ svn pg svn:eol-style foo > native > > $ svn diff foo > svn: E135001: Unrecognized line ending style > > When you add arbitrary properties to a file, produce a diff, and use it > with 'svn patch', it look like those properties get an added newline: > > $ echo bar > bar > $ svn add bar > A bar > $ svn ps testprop1 testval1 bar > property 'testprop1' set on 'bar' > $ svn ps testprop2 testval2 bar > property 'testprop2' set on 'bar' > $ svn pg testprop1 bar > testval1 > $ svn pg testprop2 bar > testval2 > $ svn diff bar > bar.diff > $ svn revert bar > Reverted 'bar' > $ rm bar > $ svn patch bar.diff > A bar > $ svn pg testprop1 bar > testval1 > > $ svn pg testprop2 bar > testval2 > > $ svn diff bar > Index: bar > === > --- bar (revision 0) > +++ bar (working copy) > @@ -0,0 +1 @@ > +bar > > Property changes on: bar > ___ > Added: testprop1 > ## -0,0 +1 ## > +testval1 > Added: testprop2 > ## -0,0 +1 ## > +testval2 > > Any idea if I'm doing something wrong here? If it seems like a bug, I'd > like to file a PR. > Index: foo > === > --- foo (revision 0) > +++ foo (working copy) > @@ -0,0 +1 @@ > +foo > > Property changes on: foo > ___ > Added: svn:eol-style > ## -0,0 +1 ## > +native
