RE: Transaction author without requiring password
>I'm trying to force commits to have an attached author, but I don't >care for requiring passwords. In other words, commits should contain >an author field but there's no enforcing that the committer is who >they claim to be. > >I've tried filtering for an author in the pre-commit hook, but the >user name given in the commit is not passed unless anon-access doesn't >given write privileges, and auth-access is enabled. Furthermore, >without a corresponding author name in the passwd file, I don't think >svnserve makes it to the pre-commit stage at all. > >Are there any recommended solutions for ensuring that commits have an >attached author, or similar field? Maybe something like this put in place as a pre-commit hook? #!/bin/bash SVNLOOK=/usr/bin/svnlook REPOPATH=$1 TRANSACTION=$2 # get user USER=`$SVNLOOK author $REPOPATH -t $TRANSACTION` # check if the user is empty if[ -z "$USER" ]; then exit 1 exit 0
Re: Transaction author without requiring password
I tried this, but an author is not passed unless auth-access is in use AFAICT. So $USER in your example is always empty. On Wed, Oct 5, 2011 at 7:16 PM, Dominik Psenner wrote: >>I'm trying to force commits to have an attached author, but I don't >>care for requiring passwords. In other words, commits should contain >>an author field but there's no enforcing that the committer is who >>they claim to be. >> >>I've tried filtering for an author in the pre-commit hook, but the >>user name given in the commit is not passed unless anon-access doesn't >>given write privileges, and auth-access is enabled. Furthermore, >>without a corresponding author name in the passwd file, I don't think >>svnserve makes it to the pre-commit stage at all. >> >>Are there any recommended solutions for ensuring that commits have an >>attached author, or similar field? > > Maybe something like this put in place as a pre-commit hook? > > #!/bin/bash > SVNLOOK=/usr/bin/svnlook > REPOPATH=$1 > TRANSACTION=$2 > > # get user > USER=`$SVNLOOK author $REPOPATH -t $TRANSACTION` > > # check if the user is empty > if[ -z "$USER" ]; then > exit 1 > exit 0 > >
RE: Transaction author without requiring password
>I tried this, but an author is not passed unless auth-access is in use >AFAICT. So $USER in your example is always empty. This would mean that you would never see any usernames in commits. Did you try to commit using the --username parameter?
how to compare an exported file (or set of files) against the repository?
Hi, I have been unable to find an answer to this in the FAQ or the mailing list archives. I found one question that appears to be similar to what I'm trying to achieve but it did not contain a reply that solves my problem. I've got a set of files that were exported from a repository some time ago. The files have been moved around and some have been edited since. I would like to find out: a) what revision these files are from and b) what changes have been made to it that may not be in the repository? Is this possible without looping through all the revisions and calculating checksums? The problem with appraoch besides the time it would take is that it would obviously not catch files that are not 100% identical to the files in that revision. Thanks in advance for any pointer that would help in this. Bram Mazda Motor Logistics Europe NV, Blaasveldstraat 162, B-2830 Willebroek VAT BE 0406.024.281, RPR Mechelen, ING 310-0092504-52, IBAN : BE64 3100 0925 0452, SWIFT : BBRUBEBB
Re: how to compare an exported file (or set of files) against the repository?
Guten Tag Mertens, Bram, am Mittwoch, 5. Oktober 2011 um 14:49 schrieben Sie: > I would like to find out: a) what revision these files are from You can't, even with comparing checksums or stuff like that you would only get any revisions where the files are the same. But you can't tell when the files were exported among your revisions. > b) what changes have been made to it that may not be in the repository? Check out a working copy and copy the files over. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: how to compare an exported file (or set of files) against the repository?
I'm a bit surprised that 'svn info URL/to/file' does not print the checksum of the file, even when the filesystem backend has the checksum stored and doesn't need to calculate it on demand. Mertens, Bram wrote on Wed, Oct 05, 2011 at 14:49:35 +0200: > Hi, > > I have been unable to find an answer to this in the FAQ or the mailing list > archives. I found one question that appears to be similar to what I'm trying > to achieve but it did not contain a reply that solves my problem. > > I've got a set of files that were exported from a repository some time ago. > The files have been moved around and some have been edited since. > > I would like to find out: a) what revision these files are from and b) what > changes have been made to it that may not be in the repository? > > Is this possible without looping through all the revisions and calculating > checksums? > The problem with appraoch besides the time it would take is that it would > obviously not catch files that are not 100% identical to the files in that > revision. > > Thanks in advance for any pointer that would help in this. > > Bram > > > > Mazda Motor Logistics Europe NV, Blaasveldstraat 162, B-2830 Willebroek > VAT BE 0406.024.281, RPR Mechelen, ING 310-0092504-52, IBAN : BE64 3100 0925 > 0452, SWIFT : BBRUBEBB >
Re: how to compare an exported file (or set of files) against the repository?
Am 05.10.2011 14:49, schrieb Mertens, Bram: I have been unable to find an answer to this in the FAQ or the mailing list archives. I found one question that appears to be similar to what I'm trying to achieve but it did not contain a > reply that solves my problem. I haven't found the need for that yet, even though I'm prepared (see below) for the situation. I've got a set of files that were exported from a repository some time ago. The files have been moved around and some have been edited since. I would like to find out: a) what revision these files are from and There are so-called keywords, which SVN can be made to replace in text files. You can for example tell it to fill in the URL and revision a file is checked out from. This can be used to attach some metadata to an exported source tree. Of course that doesn't help you know, unless someone already prepared for this case. Note that the revision of a file doesn't change if you change a different file, so it can't give you _The_ revision of the source tree. OTOH, there is no guarantee that you don't have an export from a mixed-revision working copy. b) changes have been made to it that may not be in the repository? Find out where this was exported from, and check out that revision. Copy the export on top of it and compare, or use a recursive tree comparison utility. Is this possible without looping through all the revisions and calculating checksums? The problem with appraoch besides the time it would take is that it would obviously not catch files that are not > 100% identical to the files in that revision. If the source tree contains files from several different revisions, that will be the only (hard) way to go. However, I guess you can expect that the export was made from one revision. If you know the history of the according project a bit, you might be able to find the approximate revision it was checked out and from there search for the exact revision. Another hint might be hidden in modification timestamps. BTW: The most efficient way is to check out an approximate revision and then use "svn up -r ..." to move to the next revision quickly. In particular you shouldn't use export instead of an incremental update. Good luck! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
RE: how to compare an exported file (or set of files) against the repository?
This procedure could be easily automated by a stupid script that does something like: for REV in seq 0 NEWESTREV; do svn up -r REV cp updated-file repos-file if [ -z "`svn diff`" ]; then echo "found candidate rev $REV!"; fi svn revert . done JMTC, D. >-Original Message- >From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com] >Sent: Wednesday, October 05, 2011 3:38 PM >To: users@subversion.apache.org >Subject: Re: how to compare an exported file (or set of files) against the >repository? > >Am 05.10.2011 14:49, schrieb Mertens, Bram: >> I have been unable to find an answer to this in the FAQ or the >> mailing list archives. I found one question that appears to be >> similar to what I'm trying to achieve but it did not contain a > > reply that solves my problem. > >I haven't found the need for that yet, even though I'm prepared (see >below) for the situation. > >> I've got a set of files that were exported from a repository some >> time ago. The files have been moved around and some have been >> edited since. >> >> I would like to find out: >> a) what revision these files are from and > >There are so-called keywords, which SVN can be made to replace in text >files. You can for example tell it to fill in the URL and revision a >file is checked out from. This can be used to attach some metadata to an >exported source tree. Of course that doesn't help you know, unless >someone already prepared for this case. Note that the revision of a file >doesn't change if you change a different file, so it can't give you >_The_ revision of the source tree. OTOH, there is no guarantee that you >don't have an export from a mixed-revision working copy. > > >> b) changes have been made to it that may not be in the repository? > >Find out where this was exported from, and check out that revision. Copy >the export on top of it and compare, or use a recursive tree comparison >utility. > > >> Is this possible without looping through all the revisions and >> calculating checksums? The problem with appraoch besides the time it >> would take is that it would obviously not catch files that are not > > 100% identical to the files in that revision. > >If the source tree contains files from several different revisions, that >will be the only (hard) way to go. However, I guess you can expect that >the export was made from one revision. If you know the history of the >according project a bit, you might be able to find the approximate >revision it was checked out and from there search for the exact >revision. Another hint might be hidden in modification timestamps. > >BTW: The most efficient way is to check out an approximate revision and >then use "svn up -r ..." to move to the next revision quickly. In >particular you shouldn't use export instead of an incremental update. > > >Good luck! > >Uli >*** >*** >Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland >Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 >*** >*** >Visit our website at http://www.dominolaser.com >*** >*** >Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten >bestimmt und kann vertrauliche Informationen enthalten. Bitte >benachrichtigen Sie den Absender umgehend, falls Sie nicht der >beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu >löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder >anderweitig benutzt werden. >E-Mails können durch Dritte gelesen werden und Viren sowie >nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese >Folgen nicht verantwortlich. >*** >***
Re: Transaction author without requiring password
Yes I did, and this is my deduction also. The user names won't make it to the pre-commit unless they're required to authenticate by svnserve first. On Wed, Oct 5, 2011 at 10:31 PM, Dominik Psenner wrote: >>I tried this, but an author is not passed unless auth-access is in use >>AFAICT. So $USER in your example is always empty. > > This would mean that you would never see any usernames in commits. Did you > try to commit using the --username parameter? > >
RE: how to compare an exported file (or set of files) against the repository?
> Mazda Motor Logistics Europe NV, Blaasveldstraat 162, B-2830 Willebroek VAT BE 0406.024.281, RPR Mechelen, ING 310-0092504-52, IBAN : BE64 3100 0925 0452, SWIFT : BBRUBEBB -Original Message- > From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com] > Sent: woensdag 5 oktober 2011 15:38 > To: users@subversion.apache.org > Subject: Re: how to compare an exported file (or set of files) against the > repository? > > Am 05.10.2011 14:49, schrieb Mertens, Bram: > > I have been unable to find an answer to this in the FAQ or the > > mailing list archives. I found one question that appears to be > > similar to what I'm trying to achieve but it did not contain a > > reply that solves my problem. > > I haven't found the need for that yet, even though I'm prepared (see > below) for the situation. > > > I've got a set of files that were exported from a repository some > > time ago. The files have been moved around and some have been > > edited since. > > > > I would like to find out: > > a) what revision these files are from and > > There are so-called keywords, which SVN can be made to replace in text > files. You can for example tell it to fill in the URL and revision a > file is checked out from. This can be used to attach some metadata to an > exported source tree. Of course that doesn't help you know, unless > someone already prepared for this case. Note that the revision of a file > doesn't change if you change a different file, so it can't give you > _The_ revision of the source tree. OTOH, there is no guarantee that you > don't have an export from a mixed-revision working copy. Thx for this, but I am aware of this feature and should have mentioned that it is currently not being used (though I'll be changing that). > > b) changes have been made to it that may not be in the repository? > > Find out where this was exported from, and check out that revision. Copy > the export on top of it and compare, or use a recursive tree comparison > utility. > > > > Is this possible without looping through all the revisions and > > calculating checksums? The problem with appraoch besides the time it > > would take is that it would obviously not catch files that are not > > 100% identical to the files in that revision. > > If the source tree contains files from several different revisions, that > will be the only (hard) way to go. However, I guess you can expect that > the export was made from one revision. If you know the history of the > according project a bit, you might be able to find the approximate > revision it was checked out and from there search for the exact > revision. Another hint might be hidden in modification timestamps. > > BTW: The most efficient way is to check out an approximate revision and > then use "svn up -r ..." to move to the next revision quickly. In > particular you shouldn't use export instead of an incremental update. Too bad there is no less complicated way of doing this but I guess I'll use a combination of the suggestions in this thread to accomplish what I need. If anyone has a better suggestion I'd like to hear about it still. Regards and thanks for all the feedback received so far. Bram
Re: how to compare an exported file (or set of files) against the repository?
2011/10/5 Dominik Psenner : > This procedure could be easily automated by a stupid script that does > something like: > > for REV in seq 0 NEWESTREV; do > svn up -r REV > cp updated-file repos-file > if [ -z "`svn diff`" ]; then echo "found candidate rev $REV!"; fi > svn revert . > done > Can "diff -u" command take input from stdout? Its man page says "If a FILE is `-', read standard input." If so, one could feed it from "svn cat" command. Just for record, there is "--force" flag for svn checkout command, that allows it to create a working copy over files that were exported. I think it should not overwrite files that has local changes, but have not verified whether that is true. > Check out a working copy and copy the files over. +1 Best regards, Konstantin Kolinko
Subversion 1.6.17 installation
Hi, Having trouble in installing Subversion 1.6.17 rpm since it is looking for dependency library files like libapr-1.so, libaprutil-1.so and libneon.so. Is that any one give me the URL to download the subversion 1.6.17 installable. -- Regards, Muthu Kalimuthu Samayan Mobile: 0044+(0)782 122 7480
Re: svn merge operation extremely slow
On Mon, Oct 3, 2011 at 9:55 AM, Johan Corveleyn wrote: > On Mon, Oct 3, 2011 at 3:04 PM, Stefan Sperling wrote: > > On Mon, Oct 03, 2011 at 02:59:25PM +0200, Johan Corveleyn wrote: > >> On Mon, Oct 3, 2011 at 2:35 PM, Johan Corveleyn > wrote: > >> > On Mon, Oct 3, 2011 at 2:16 PM, Kyle Leber > wrote: > >> >> I set the mime-type to "application/octet-stream" in the working copy > prior > >> >> to merge and this fixed the problem. No more heavy CPU usage or > excessive > >> >> time spent on the file. > >> > > >> > I'm glad it helped. Apart from the performance, it's important that > >> > svn does this merge the "binary way", because as you said line-based > >> > merges are not correct for this file. > >> > >> It may also interest you (and other readers of this thread) that there > >> is an open enhancement request for making text-merges take the same > >> shortcut as binary-merges (if mine == merge-left then set merged := > >> merge-right), to avoid expensive diffing [1]. But that hasn't been > >> addressed yet. > >> > >> > >> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4009 : Big > >> trivial text files merged MUCH slower than binary - pls optimize. > >> > > > > I think we should also file an issue about the problem discussed > > in this thread. svn should take properties on the left/right side of the > > merge into account when determining whether to treat a file as binary. > > I guess it should run the binary merge if any of left, right, or the > > target are marked as binary. > > Yes, maybe you're right. I don't know the specifics / historics of > this behavior (maybe there is a reason for this?). But on the surface > it looks like it should indeed do a binary merge if either one of > left, right or target is marked as binary. > > Even if #4009 would be addressed, it would still make a difference in > the situation where the shortcut-condition (mine == merge-left) > doesn't hold. In that case, I think the "binary-merge" would always > flag a conflict (because it can't do a line-based merge). Is that also > the behavior we want f.i. if only merge-left (or only merge-right) > were marked as binary, and all the other "players" are marked as text? > I guess it's the safest thing to do ... > > -- > Johan > Did someone already file this issue, or do you need me to? I have never done this before, but can certainly make an attempt if this is what's needed. - Kyle
