Re: Is there a way to dump the checksums from a svn repo?
Guten Tag olli hauer, am Mittwoch, 28. November 2012 um 22:45 schrieben Sie: > Someone hacks one of the additional mirrors, modifies a revision and adjust > the > checksum (as described on many places how-to fix a corrupt repo) so it looks > OK > even with svnadmin verify. Sounds interesting, but if the mirrors not under your full control already have been hacked how can you trust the locally produced checksums by svnadmin? You can't as you can't trust the mirror in any way, svnadmin could be manipulated, too, you would need to get the data to a trustful environment again and check it from there. You solution wouldn't even scale as you had to recalculate all checksums and compare all revisions all over again, you wouldn't have any point in time where you could say that the first million revisions are totally OK and could rely on that in the future. I would think in another direction and use digital signatures to be able to detect changes to revisions after the approval that there in a consistent state with the master. Get unsigned revisions from the mirrors, compare them file by file using hashes with the revisions you trust and if everything is ok sign them. Depending on your mirrors and the security you need you wouldn't even need to copy the data, just make it accessible for read access during ssh or whatever. The benefit is you could use already available tools and would only need to check unsigned revisions, but can check the integrity of the already signed revisions really fast and whenever you like. The signature information for each revision file or checked block, however you would implement such an approach, can even be stored on the untrustful mirrors, nor problem as nobody else than you and however you trust is able to create valid signatures. Just an idea, as signatures were exactly made for such purposes were one has to detect data manipulation in any way. Besides that, maybe have look at the mirroring products of WanDisco, it's possible that they already have a solution. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: crash report and minidump
Guten Tag Karla Sylvester, am Mittwoch, 28. November 2012 um 22:17 schrieben Sie: > This seem happened after I upgraded Slik-Subversion to 1.7.7 (from > 1.7.5, I believe). The same thing is happening on two different > machines, both Windows. When I do a checkout from a Linux machine, I > have no problem. http://mail-archives.apache.org/mod_mbox/subversion-users/201211.mbox/%3c20121104101302.gd27...@ted.stsp.name%3E Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Purging old Revisions
There were some binary files that were included as part of the projects that weren't necessary, so its tons of seemingly small mistakes. The repository was started 5 1/2 years ago. Revision #6,000 was about 2 years ago. I have never used any history older than 24 months. Even though 10 GB doesn't seem big, about 2/3 of it is a waste, so its wasting time and money. I agree that the whole idea is too keep the history, but oldest transactions provide the least value for me. mb On Wed, Nov 28, 2012 at 4:28 PM, Andy Levy wrote: > > > On Wed, Nov 28, 2012 at 4:18 PM, Matthew Bluhm wrote: > >> My repository is now over 10GB and it is rather cumbersome to take care >> of. >> >> There has been many mistakes such as committing extra files. >> >> The older revisions provide no value and only cause headaches. >> >> I initially thought that I could export out the repository at revision >> 6,000 then just apply a dump of transactions 6,001 to HEAD >> >> > > > Do you truly have 6000 revisions - two thirds of your whole repository - > which have NO value whatsoever? Probably not. Those revisions are the > history of what you're producing. In the grand scheme of things, a 10GB > repository isn't really that large. > > Rather than throw away *all* of your history, have you considered the > possibility of removing just those revisions where large files (ISO images) > which never should have been committed? This will preserve your history and > reduce your repository size, and skip throwing the baby out with the > bathwater. > > > On Wed, Nov 28, 2012 at 3:42 PM, Les Mikesell wrote: >> >>> On Wed, Nov 28, 2012 at 2:36 PM, Andy Levy wrote: >>> > >>> >> Is there an easy way to purge out the earliest 6,000 Revisions of the >>> >> 9,600 that are in my repository? >>> >> >>> >> In a perfect world I would keep my revision numbers and timestamps, >>> but >>> >> that isn't 100% required. >>> >> >>> > >>> > Short answer: No. >>> > >>> > Longer answer: It can be done, but everyone will have to check out new >>> > working copies and you might get weird results due to the loss of >>> history. >>> > There is no "easy" way to do it, but if all you're doing is cutting >>> off the >>> > first X revisions it's not the most complex task. You will keep the >>> commit >>> > timestamps, but the revision numbers will be reset (unless you enter >>> dummy >>> > revisions, which will then make your repository appear to own a >>> modified >>> > DeLorean, unless you then further mangle those dummy revisions to >>> change >>> > their timestamps). >>> > >>> > Version control systems are designed to keep your history. "Purging" >>> goes >>> > against this core concept. Why are you embarking on this endeavor? >>> >>> It's pretty much just a matter of time until someone does something >>> that shouldn't have been done in any repository. Even if the answer >>> is always going to be 'it can't be done', why question the motives of >>> someone trying to fix things? >>> >>> -- >>>Les Mikesell >>> lesmikes...@gmail.com >>> >> >> >
Re: Is there a way to dump the checksums from a svn repo?
On 2012-11-25 21:49, Thorsten Schöning wrote: > Guten Tag olli hauer, > am Sonntag, 25. November 2012 um 20:18 schrieben Sie: > >> Thanks for every answer and code snippet ... > > I'm interested in which problem you try to solve with your approach? > What's the reason behind it? Maybe there are other ways to accomplish > what you want. > > Mit freundlichen Grüßen, > > Thorsten Schöning > Sorry for the delay ... I will try to explain some of my thoughts. Given you have one svn master from where dedicated slaves are syncing Both master and first slaves are under your control so far so good. Now some additional mirrors which are not under you full control are syncing from the slaves to help offload traffic. Someone hacks one of the additional mirrors, modifies a revision and adjust the checksum (as described on many places how-to fix a corrupt repo) so it looks OK even with svnadmin verify. Now if you have a million of revisions it will be hard to detect such an issue. Wouldn't it be nice to have the ability to calculate the checksums regularly so they can be compared with the upstream checksums? Another methode to detect such thing would be rsync the repo first with a dry-run and then do a live sync but svnsync is preferred. -- Regards, olli
Re: Purging old Revisions
On Wed, Nov 28, 2012 at 3:18 PM, Thorsten Schöning wrote: >> >> Does the answer change based on this? > > One can maybe make more clear why removing versions may have not the > desired effect at all and is therefore just a waste of time. Your > accidently committed and never changed images are one example, but in > the past there were questions were users tried to save disk space of > files which get changed regularly but didn't knew of deltas, > representation sharing etc. In both cases one would answer > differently. > OK, but I've probably got all of the above in one 60G+ repository. Is the best I can hope for that disk prices will keep going down (and speed up, in case I ever have to restore from a backup...)? -- Les Mikesell lesmikes...@gmail.com
Re: Purging old Revisions
On Wed, Nov 28, 2012 at 4:18 PM, Matthew Bluhm wrote: > My repository is now over 10GB and it is rather cumbersome to take care of. > > There has been many mistakes such as committing extra files. > > The older revisions provide no value and only cause headaches. > > I initially thought that I could export out the repository at revision > 6,000 then just apply a dump of transactions 6,001 to HEAD > > Do you truly have 6000 revisions - two thirds of your whole repository - which have NO value whatsoever? Probably not. Those revisions are the history of what you're producing. In the grand scheme of things, a 10GB repository isn't really that large. Rather than throw away *all* of your history, have you considered the possibility of removing just those revisions where large files (ISO images) which never should have been committed? This will preserve your history and reduce your repository size, and skip throwing the baby out with the bathwater. On Wed, Nov 28, 2012 at 3:42 PM, Les Mikesell wrote: > >> On Wed, Nov 28, 2012 at 2:36 PM, Andy Levy wrote: >> > >> >> Is there an easy way to purge out the earliest 6,000 Revisions of the >> >> 9,600 that are in my repository? >> >> >> >> In a perfect world I would keep my revision numbers and timestamps, but >> >> that isn't 100% required. >> >> >> > >> > Short answer: No. >> > >> > Longer answer: It can be done, but everyone will have to check out new >> > working copies and you might get weird results due to the loss of >> history. >> > There is no "easy" way to do it, but if all you're doing is cutting off >> the >> > first X revisions it's not the most complex task. You will keep the >> commit >> > timestamps, but the revision numbers will be reset (unless you enter >> dummy >> > revisions, which will then make your repository appear to own a modified >> > DeLorean, unless you then further mangle those dummy revisions to change >> > their timestamps). >> > >> > Version control systems are designed to keep your history. "Purging" >> goes >> > against this core concept. Why are you embarking on this endeavor? >> >> It's pretty much just a matter of time until someone does something >> that shouldn't have been done in any repository. Even if the answer >> is always going to be 'it can't be done', why question the motives of >> someone trying to fix things? >> >> -- >>Les Mikesell >> lesmikes...@gmail.com >> > >
crash report and minidump
This seem happened after I upgraded Slik-Subversion to 1.7.7 (from 1.7.5, I believe). The same thing is happening on two different machines, both Windows. When I do a checkout from a Linux machine, I have no problem. Thanks for the help, -- Karla Sylvester Senior Software Engineer Wegmann USA, Inc Training & Simulation Office: 407-381-6004 svn-crash-log20121128160202.dmp Description: Binary data Process info: Cmd line: "C:/Program Files/SlikSvn/bin/svn.exe" checkout --username Karla http://71.46.229.226:8181/svn/sysmanager/sysmanager-agent/trunk sysmanager-agent Working Dir: C:\workspace\buildsystem Version: 1.7.7-SlikSvn-1.7.7-X64 (SlikSvn/1.7.7) X64, compiled Oct 9 2012, 15:02:20 Platform: Windows OS version 6.1 build 7601 Service Pack 1 Exception: ACCESS_VIOLATION Registers: Rax= Rcx= Rdx= Rbx=002cee34 Rsp=002ced70 Rbp=002cee38 Rsi=005c0038 Rdi= R8= R9= fffd1c50 R10= 77c87c50 R11=004ebae0 R12= R13=005c0038 R14=00626870 R15=002cef10 cs=0033 ss=002b ds=002b es=0053 fs=002b gs=002b ss=0094 Stacktrace: #1 0x7fb7127 in svn_auth_get_username_prompt_provider() #2 0x7fb3a7f in svn_auth_get_platform_specific_client_providers() #3 0x7fb7235 in svn_auth_get_username_prompt_provider() #4 0x7fb2f20 in svn_auth_first_credentials() #5 0x7feee834583 in svn_ra_local_init() #6 0x7feee875be0 in svn_ra_get_ra_library() #7 0x7feee87526c in svn_ra_get_ra_library() #8 0x7feee8757ef in svn_ra_get_ra_library() #9 0x7feee87801a in svn_ra_get_ra_library() #10 0x7feee8780b9 in svn_ra_get_ra_library() #11 0x7feee845c05 in svn_ra_dav_init() #12 0x7feee837db9 in svn_ra_dav_init() #13 0x7feee835b3c in svn_ra_local_init() #14 0x7feee86cb55 in svn_ra_open4() #15 0x7fef676e134 in svn_client_suggest_merge_sources() #16 0x7fef676f11b in svn_client_uuid_from_path2() #17 0x7fef674a785 in svn_client_cat2() #18 0x7fef674ab99 in svn_client_checkout3() #19 0x13f2f2338 in (unknown function) #20 0x13f2fa44a in (unknown function) #21 0x13f3047ee in (unknown function) #22 0x775e652d in BaseThreadInitThunk() #23 0x77b7c521 in RtlUserThreadStart() Loaded modules: 0x3f2f C:\Program Files\SlikSvn\bin\svn.exe (1.7.7.17343, 241664 bytes) 0x77b5 C:\Windows\System32\ntdll.dll (6.1.7601.17725, 1740800 bytes) 0x775d C:\Windows\System32\kernel32.dll (6.1.7601.17932, 1175552 bytes) 0xfe27 C:\Windows\System32\KERNELBASE.dll (6.1.7601.17932, 442368 bytes) 0x6eec C:\Program Files\SlikSvn\bin\SlikSvn-libintl-x64.dll (0.0.0.0, 61440 bytes) 0x71a5 C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_08e61857a83bc251\msvcr90.dll (9.0.30729.6161, 667648 bytes) 0x000e C:\Program Files\SlikSvn\bin\SlikSvn-libapr-1.dll (1.4.6.0, 184320 bytes) 0xff9f C:\Windows\System32\ws2_32.dll (6.1.7601.17514, 315392 bytes) 0xff61 C:\Windows\System32\msvcrt.dll (7.0.7601.17744, 651264 bytes) 0xff84 C:\Windows\System32\rpcrt4.dll (6.1.7601.17514, 1232896 bytes) 0xff75 C:\Windows\System32\nsi.dll (6.1.7600.16385, 32768 bytes) 0xfd76 C:\Windows\System32\mswsock.dll (6.1.7601.17514, 348160 bytes) 0x77a5 C:\Windows\System32\user32.dll (6.1.7601.17514, 1024000 bytes) 0xff3b C:\Windows\System32\gdi32.dll (6.1.7601.17514, 421888 bytes) 0xffe5 C:\Windows\System32\lpk.dll (6.1.7600.16385, 57344 bytes) 0xfe42 C:\Windows\System32\usp10.dll (1.626.7601.17561, 823296 bytes) 0xff42 C:\Windows\System32\advapi32.dll (6.1.7600.16385, 897024 bytes) 0xfe4f C:\Windows\System32\sechost.dll (6.1.7600.16385, 126976 bytes) 0xfe62 C:\Windows\System32\shell32.dll (6.1.7601.17859, 14188544 bytes) 0xff7c C:\Windows\System32\shlwapi.dll (6.1.7601.17514, 462848 bytes) 0xf674 C:\Program Files\SlikSvn\bin\SlikSvn-svn_client-1.dll (1.7.7.17343, 352256 bytes) 0x6ee6 C:\Program Files\SlikSvn\bin\SlikSvn-libaprutil-1.dll (1.5.1.0, 258048 bytes) 0xf90d C:\Program Files\SlikSvn\bin\SlikSvn-svn_delta-1.dll (1.7.7.17343, 110592 bytes) 0xeeeb C:\Program Files\SlikSvn\bin\SlikSvn-svn_subr-1.dll (1.7.7.17343, 958464 bytes) 0xffc4 C:\Windows\System32\ole32.dll (6.1.7601.17514, 2109440 bytes) 0xfe06 C:\Windows\System32\crypt32.dll (6.1.7601.17856, 1482752 bytes) 0xfe05 C:\Windows\System32\msasn1.dll (6.1.7601.17514, 61440 bytes) 0xf8bf C:\Program Files\SlikSvn\bin\SlikSvn-svn_diff-1.dll (1.7.7.17343, 86016 bytes) 0xee83 C:\Program Files\SlikSvn\bin\SlikSvn-svn_ra-1.dll (1.7.7.17343, 532480 bytes) 0xf669 C:\Program Files\SlikSvn\bin\SlikSvn-svn_repos-1.dll (1.7.7.17343, 196608 bytes) 0xf13e C:\Program Files\SlikSvn\bin\SlikSvn-svn_fs-1.dll (1.7.7.17343, 323584 bytes) 0x1300 C:\Program Files\SlikSvn\bin\SlikSvn-DB44-20-x64.dll (4.0.4.20, 933888 bytes) 0x6ec6 C:\Windows\winsxs\amd64_micros
Re: Purging old Revisions
My repository is now over 10GB and it is rather cumbersome to take care of. There has been many mistakes such as committing extra files. The older revisions provide no value and only cause headaches. I initially thought that I could export out the repository at revision 6,000 then just apply a dump of transactions 6,001 to HEAD Thanks for your help On Wed, Nov 28, 2012 at 3:42 PM, Les Mikesell wrote: > On Wed, Nov 28, 2012 at 2:36 PM, Andy Levy wrote: > > > >> Is there an easy way to purge out the earliest 6,000 Revisions of the > >> 9,600 that are in my repository? > >> > >> In a perfect world I would keep my revision numbers and timestamps, but > >> that isn't 100% required. > >> > > > > Short answer: No. > > > > Longer answer: It can be done, but everyone will have to check out new > > working copies and you might get weird results due to the loss of > history. > > There is no "easy" way to do it, but if all you're doing is cutting off > the > > first X revisions it's not the most complex task. You will keep the > commit > > timestamps, but the revision numbers will be reset (unless you enter > dummy > > revisions, which will then make your repository appear to own a modified > > DeLorean, unless you then further mangle those dummy revisions to change > > their timestamps). > > > > Version control systems are designed to keep your history. "Purging" goes > > against this core concept. Why are you embarking on this endeavor? > > It's pretty much just a matter of time until someone does something > that shouldn't have been done in any repository. Even if the answer > is always going to be 'it can't be done', why question the motives of > someone trying to fix things? > > -- >Les Mikesell > lesmikes...@gmail.com >
Re: Purging old Revisions
Guten Tag Les Mikesell, am Mittwoch, 28. November 2012 um 22:00 schrieben Sie: > Does the answer change based on this? One can maybe make more clear why removing versions may have not the desired effect at all and is therefore just a waste of time. Your accidently committed and never changed images are one example, but in the past there were questions were users tried to save disk space of files which get changed regularly but didn't knew of deltas, representation sharing etc. In both cases one would answer differently. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Purging old Revisions
On Wed, Nov 28, 2012 at 3:42 PM, Les Mikesell wrote: > On Wed, Nov 28, 2012 at 2:36 PM, Andy Levy wrote: > > > >> Is there an easy way to purge out the earliest 6,000 Revisions of the > >> 9,600 that are in my repository? > >> > >> In a perfect world I would keep my revision numbers and timestamps, but > >> that isn't 100% required. > >> > > > > Short answer: No. > > > > Longer answer: It can be done, but everyone will have to check out new > > working copies and you might get weird results due to the loss of > history. > > There is no "easy" way to do it, but if all you're doing is cutting off > the > > first X revisions it's not the most complex task. You will keep the > commit > > timestamps, but the revision numbers will be reset (unless you enter > dummy > > revisions, which will then make your repository appear to own a modified > > DeLorean, unless you then further mangle those dummy revisions to change > > their timestamps). > > > > Version control systems are designed to keep your history. "Purging" goes > > against this core concept. Why are you embarking on this endeavor? > > It's pretty much just a matter of time until someone does something > that shouldn't have been done in any repository. Even if the answer > is always going to be 'it can't be done', why question the motives of > someone trying to fix things? It's not so much about the motives as it is understanding why so that an appropriate answer can be provided. IOW, describe the *problem*, not the perceived solution. See also http://www.perlmonks.org/index.pl?node_id=542341
Re: svn:executable is ignored on checkout form Windows to Samba share
Guten Tag Daniel Shahaf,
am Mittwoch, 28. November 2012 um 21:36 schrieben Sie:
> And that's one of the reasons behind the standard recommendation not to
> access a single working copy from multiple systems, especally windows
> and non-windows.
Thanks, looks like I would really be better off changing some habits.
> You might try 'revert' or 'cleanup'.
I decided for a little script like the following which just adds the
execute permissions for needed files and should be faster.
# Iterator given directories, search files, change permissions:
for dir in "$@"
do
if [ ! -d "$dir" ]; then
continue
fi
# Recursively find all Perl files which don't have any execute bit set:
for file in $(find "$dir" -type f -iname "*.pl" ! -perm /111 -exec echo {} \;)
do
# svn:executable is a flag which stores * as value:
if [ "`svn propget svn:executable "$file" 2> /dev/null`" ]; then
chmod ug+x "$file"
fi
done
done
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...05151- 9468- 55
Fax...05151- 9468- 88
Mobil..0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Purging old Revisions
On Wed, Nov 28, 2012 at 2:50 PM, Thorsten Schöning wrote: > Guten Tag Les Mikesell, > am Mittwoch, 28. November 2012 um 21:42 schrieben Sie: > >> It's pretty much just a matter of time until someone does something >> that shouldn't have been done in any repository. Even if the answer >> is always going to be 'it can't be done', why question the motives of >> someone trying to fix things? > > Because the reason for the question may be an accidently committed > very important password or key to the world nobody should ever know > of, but there already have been performance related question and/or > some wanted to preserve disk space by only keeping most recent > versions and in those cases it's more then questionable if the > removable of versions will result in any benefit. In the scenarios I > read in the past it wouldn't. Does the answer change based on this? I'm pretty sure we have a mistakenly-committed DVD iso image or two AND some passwords that shouldn't be there. And some stuff imported from cvs in the wrong place, then moved, that I'd like to clean up so in the future those projects could be dumped and extracted separately. Starting over, I think I'd go one project per repository but at the time it seemed like access control would be cumbersome. -- Les Mikesell lesmikes...@gmail.com
Re: Purging old Revisions
Guten Tag Les Mikesell, am Mittwoch, 28. November 2012 um 21:42 schrieben Sie: > It's pretty much just a matter of time until someone does something > that shouldn't have been done in any repository. Even if the answer > is always going to be 'it can't be done', why question the motives of > someone trying to fix things? Because the reason for the question may be an accidently committed very important password or key to the world nobody should ever know of, but there already have been performance related question and/or some wanted to preserve disk space by only keeping most recent versions and in those cases it's more then questionable if the removable of versions will result in any benefit. In the scenarios I read in the past it wouldn't. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Purging old Revisions
On Wed, Nov 28, 2012 at 2:36 PM, Andy Levy wrote: > >> Is there an easy way to purge out the earliest 6,000 Revisions of the >> 9,600 that are in my repository? >> >> In a perfect world I would keep my revision numbers and timestamps, but >> that isn't 100% required. >> > > Short answer: No. > > Longer answer: It can be done, but everyone will have to check out new > working copies and you might get weird results due to the loss of history. > There is no "easy" way to do it, but if all you're doing is cutting off the > first X revisions it's not the most complex task. You will keep the commit > timestamps, but the revision numbers will be reset (unless you enter dummy > revisions, which will then make your repository appear to own a modified > DeLorean, unless you then further mangle those dummy revisions to change > their timestamps). > > Version control systems are designed to keep your history. "Purging" goes > against this core concept. Why are you embarking on this endeavor? It's pretty much just a matter of time until someone does something that shouldn't have been done in any repository. Even if the answer is always going to be 'it can't be done', why question the motives of someone trying to fix things? -- Les Mikesell lesmikes...@gmail.com
Re: Purging old Revisions
On Wed, Nov 28, 2012 at 3:10 PM, Matthew Bluhm wrote: > > Is there an easy way to purge out the earliest 6,000 Revisions of the > 9,600 that are in my repository? > > In a perfect world I would keep my revision numbers and timestamps, but > that isn't 100% required. > > Short answer: No. Longer answer: It can be done, but everyone will have to check out new working copies and you might get weird results due to the loss of history. There is no "easy" way to do it, but if all you're doing is cutting off the first X revisions it's not the most complex task. You will keep the commit timestamps, but the revision numbers will be reset (unless you enter dummy revisions, which will then make your repository appear to own a modified DeLorean, unless you then further mangle those dummy revisions to change their timestamps). Version control systems are designed to keep your history. "Purging" goes against this core concept. Why are you embarking on this endeavor?
Re: svn:executable is ignored on checkout form Windows to Samba share
Thorsten Schöning wrote on Wed, Nov 28, 2012 at 18:13:44 +0100: > Hello, > > I have some working copies on Samba shares, Ubuntu 12.04 LTS with all > updates installed, which are accessed using TortoiseSVN 1.7.10 which > uses Subversion 1.7.7. Some of those working copies contain executable > Perl scripts with proper svn:executable defined as *, but depending on > my Samba configuration the executable bit gets set or not. It only > gets set if Smaba is configured to force specific permissions > including the executable bit. If I checkout natively using a > Subversion client on the shell the executable bits get properly > applied. > > Is the svn:executable property completely ignored on operations which > are applied using Windows clients? I thought/hoped that Windows just I think this is the code you're looking for: 631 /* Tweak the on-disk file according to its properties. */ 632 #ifndef WIN32 633 if (props && apr_hash_get(props, SVN_PROP_EXECUTABLE, APR_HASH_KEY_STRING)) 634 SVN_ERR(svn_io_set_file_executable(local_abspath, TRUE, FALSE, 635scratch_pool)); 636 #endif What will happen is that, whenever a file is modified (eg, by 'update' or 'switch'), the Windows client will write a new file and rename(2) it on top of the old file... resetting the +x bit (to its default value) in the process. And that's one of the reasons behind the standard recommendation not to access a single working copy from multiple systems, especally windows and non-windows. > ignores anything regarding svn:executable if it's done to itself but > Samba could maybe recognize those permissions. This doesn't seem to be > the case. > > If Windows clients ignore applying svn:executable, do you have any > ideas on how I could configure Samba to just apply it on Perl scripts? You might try 'revert' or 'cleanup'. But keep in mind that being able to share a wc across operating systems might not work indefintiely... > The shares are pretty general and I don't want e.g. CSS files to have > the executable bit set. The only solution I found was a cron job > regularly finding and fixing Perl scripts as Samba doesn't seem to > provide any file type filters. > > Thanks for any hints. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...05151- 9468- 55 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow >
Purging old Revisions
Is there an easy way to purge out the earliest 6,000 Revisions of the 9,600 that are in my repository? In a perfect world I would keep my revision numbers and timestamps, but that isn't 100% required.
RE: File status control
Hello, Armando. Here we also do IEC / ISO workflows. We use the same svn repository for all kind of artifacts (source code, specs, reports, schematics...). We use tags for everything. For instance, we tag the documents alongside the reports that 'prove' that have been reviewed by who and when. Tag names show the status (for instance, spec document before review, spec document after review, spec document after approval). We find this enough for our purposes. HTH.
svn:executable is ignored on checkout form Windows to Samba share
Hello, I have some working copies on Samba shares, Ubuntu 12.04 LTS with all updates installed, which are accessed using TortoiseSVN 1.7.10 which uses Subversion 1.7.7. Some of those working copies contain executable Perl scripts with proper svn:executable defined as *, but depending on my Samba configuration the executable bit gets set or not. It only gets set if Smaba is configured to force specific permissions including the executable bit. If I checkout natively using a Subversion client on the shell the executable bits get properly applied. Is the svn:executable property completely ignored on operations which are applied using Windows clients? I thought/hoped that Windows just ignores anything regarding svn:executable if it's done to itself but Samba could maybe recognize those permissions. This doesn't seem to be the case. If Windows clients ignore applying svn:executable, do you have any ideas on how I could configure Samba to just apply it on Perl scripts? The shares are pretty general and I don't want e.g. CSS files to have the executable bit set. The only solution I found was a cron job regularly finding and fixing Perl scripts as Samba doesn't seem to provide any file type filters. Thanks for any hints. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
RE: Pre-commit fails when executing 'svn ls'
Yes, it was the SELinux messing with my life again, it works now! (it actually saved my afternoon, I was debugging it for a loog time already) Since this is a test//prototype environment, I've turned the SELinux it off completely (is ok for me). However, it would be nice to know how to properly allow it with the SELinux ON). * I will look in to it as soon as I can and post here when I have something. (if someone has already the configurations pls put them here too) Thanks a lot for the help! From: Thorsten Schöning [tschoen...@am-soft.de] Sent: 28 November 2012 16:57 To: users@subversion.apache.org Subject: Re: Pre-commit fails when executing 'svn ls' Guten Tag armando.perico.n...@usi.ch, am Mittwoch, 28. November 2012 um 16:43 schrieben Sie: > svn: OPTIONS of 'http://localhost/svn/repo/test.txt": could not > connect to server (http://localhost) SELInux or AppArmor may prevent communication as both work on binaries I think, not on users, therefore your test would succeed. A lot of people having issues like that if they try to send mails using httpd: http://stackoverflow.com/questions/1462941/php-mail-works-from-command-line-but-not-apache/1467900#1467900 Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Pre-commit fails when executing 'svn ls'
Guten Tag armando.perico.n...@usi.ch, am Mittwoch, 28. November 2012 um 16:43 schrieben Sie: > svn: OPTIONS of 'http://localhost/svn/repo/test.txt": could not > connect to server (http://localhost) SELInux or AppArmor may prevent communication as both work on binaries I think, not on users, therefore your test would succeed. A lot of people having issues like that if they try to send mails using httpd: http://stackoverflow.com/questions/1462941/php-mail-works-from-command-line-but-not-apache/1467900#1467900 Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Pre-commit fails when executing 'svn ls'
Hi, I want to write a pre-commit hook which make some checks on the repository using "svn" commands. i.e.: svn ls... however, svn ls is failing to connect to localhost. on my pre-commit file I have: --- # I don't need the $REPOS value since this is just a test svn ls http://localhost/svn/repo/ --username=X --password=Y --non-interactive exit 0 --- The script works fine when I run it "manually" (even when I run it with the "apache" user) example: sudo -u apache env /var/www/svn/hooks/precommit (works ok) su -s /bin/sh apache -c "/var/www/svn/hooks/precommit" (works ok) however, when I run it with any "svn client" I get the following: svn: OPTIONS of 'http://localhost/svn/repo/test.txt": could not connect to server (http://localhost) I can't understand why it is failing. Would anybody have a suggestion ? Thanks
Re: Restoring an archive from backup, and then?
Guten Tag Niemann, Hartmut, am Mittwoch, 28. November 2012 um 12:42 schrieben Sie: > But how should one recover in such a situation? > Is a fresh checkout and a manual merge necessary? Yes, the missing versions between you backup and the current working copy are lost and your working copies can only be used to re-commit the missing data in which ever order you like best. So move them out of the way, create new working copies and integrate the data from your old working copies by e.g. just copying the data on file system level. A real subversion merge will not be possible. You should re-consider your backup strategy, most people use svnsync or another incremental backup method in post commit hooks or whatever. http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.backup Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Restoring an archive from backup, and then?
Wed, Nov 28, 2012 at 6:42 AM, Niemann, Hartmut wrote: > ** > Hello! > Our SVN server had a disk failure and some projects had to be restored > from the nightly backup. > > What happens in such a case, if my working copy is on revision 120 and the > latest revision in the restored archive is 110? > > I did some tests and it looks like subversion detects that (I used > TortoiseSVN 1.7.10 on windows using the svn core library 1.7.7). > So at least it looks like a newer working copy can not be overwritten > incidentially by the restored (older) HEAD revision. > > But how should one recover in such a situation? > Is a fresh checkout and a manual merge necessary? > > > Yes, you will need to check out fresh WCs & manually get as much of those missing 10 revisions into the repository.
Re: Restoring an archive from backup, and then?
Niemann, Hartmut wrote on Wed, Nov 28, 2012 at 12:42:44 +0100: > So at least it looks like a newer working copy can not be overwritten > incidentially by the restored (older) HEAD revision. It's not that simple --- once you commit 11 revisions to the restored repository, you'll get some... interesting errors. > > But how should one recover in such a situation? > Is a fresh checkout and a manual merge necessary? > Yes. And change the UUID of the recovered repository --- to account for the problem above (basically, post-r110 history forked).
Restoring an archive from backup, and then?
Hello! Our SVN server had a disk failure and some projects had to be restored from the nightly backup. What happens in such a case, if my working copy is on revision 120 and the latest revision in the restored archive is 110? I did some tests and it looks like subversion detects that (I used TortoiseSVN 1.7.10 on windows using the svn core library 1.7.7). So at least it looks like a newer working copy can not be overwritten incidentially by the restored (older) HEAD revision. But how should one recover in such a situation? Is a fresh checkout and a manual merge necessary? Mit freundlichen Grüßen Dr. Hartmut Niemann Siemens AG Infrastructure & Cities Sector Rail Systems Division Locomotives and Components IC RL LOC EN LE 8 Werner-von-Siemens-Str. 67 91052 Erlangen, Deutschland Tel.: +49 9131 7-34264 Fax: +49 9131 7-26254 mailto:hartmut.niem...@siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Peter Löscher, Vorsitzender; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Süß; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
