Subversion Client on z/OS
Hi, If you provide us any information about the subject, we'd be very happy. Currently we are using CVS for Open platform SCM tool. We are going to move to SVN soon. At the same time we want use SVN for CICS/DB2 COBOL source code currently edited by z/OS ISPF environment. We don't want to change any build environment. Expecting scenario is as follows: 1. CICS/DB2 master source code are in SVN repository on LINUX platform. 2. Developer CHECK-OUT some source code members form the SVN repository to z/OS PDS(Partitioned Data Set) edited by ISPF. 3. Developer works, update the code, compile, link/edit on z/OS environment using ISPF/SDSF. 4. Then, the developer COMMIT their code to the SVN repository. Questions: a) Is there any SVN client available for z/OS implementing my scenario above I found a couple experiences on this subject, but the results was NOT clear. http://mail-archives.apache.org/mod_mbox/subversion-dev/201011.mbox/%3CAANLkTinFCn_ugO4OFXYfHuAB=yqkkq1e+eioy9dbs...@mail.gmail.com%3E b) If it is there, where does the executable module run?? It runs on ISPF command line??? c) If you have any best practice on this subject please let me know. Any comments would be very useful for us. Thanks in advanced, best regards, Iwao
Re: FreeBSD project and subversion.
On Tue, Feb 5, 2013 at 1:39 AM, Alexey Neyman wrote: > On Monday, February 04, 2013 10:17:29 PM Stefan Sperling wrote: > >> On Mon, Feb 04, 2013 at 11:54:21AM -0800, Alexey Neyman wrote: > >> > On Thursday, January 31, 2013 09:08:20 am Stefan Sperling wrote: > >> > > BTW, I went over one of FreeBSD's svn wiki pages a while back, and >> > > added > >> > > answers to open questions on this page: > >> > > https://wiki.freebsd.org/SubversionMissing > >> > > >> > Speaking of which: > >> > > >> > Is there a reason why it is necessary to use "the svn diff --old > >> > ^/somebranch --new ." instead of the intuitive "svn ^/somebranch ."? > >> > >> Would "svn diff ^/somebranch ." be synopsis 1? > >> > >> svn diff -rN:M ^/somebranch@HEAD .@HEAD > > > > It cannot be "synopsis 1", as its description states that "TARGETs may be > all working copy paths or all URLs". In this case, we have one of each. > Moreover, synopsis 1 says that for URLs, -r or -c must be present - and my > example has no -r/-c option. Sorry, that's not true. From 'svn help diff' of 1.7: diff (di): Display the differences between two revisions or paths. usage: 1. diff [-c M | -r N[:M]] [TARGET[@REV]...] 2. diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]] \ [PATH...] 3. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV] So for usage 1 the -c and -r are optional. Also, the condition "may be all working copy paths or all URLs" is pretty weak for deciding to use usage 1, because for usage 2 (--old/--new) you can just as well use two working copy paths or two URLs. I think it would be even more confusing if 'svn diff A B' would decide to use usage 1 if they are both URLs or both wc paths, and use usage 2 if only one of them is a URL and the other a wc path (even though usage 2 can just as well accomodate two URLs and two wc paths). > > So, the only possible use of this syntax would be synopsis 2: > > > >> svn diff --old ^/somebranch@HEAD --new .@HEAD > >> (i.e. show the difference between the two (path, revision) pairs > >> somebranch@HEAD and .@HEAD) ? > >> > >> > It has bugged me for a while until I discovered this --old/--new trick. > >> > >> I agree that --old --new syntax isn't intuitive at all. > > > > What adds oil to the fire is that the error message, which claims that > "Target lists to diff may not contain both working copy paths and URL". If > instead it said that the supplied syntax is ambiguous and suggested to use > --new/--old for disambiguation, this would have saved a lot of frustration > and would eliminate the need of "svn compare" subcommand :) > > > > For example: > > svn: Ambiguous target list (contains both work copy paths and URLs). Use > > --old/--new syntax to disambiguate. > Given what I said above, this can't be done in general (not if you give two URLs or two wc paths, because then both synopsis 1 and 2 are possible -- it would obviously break backwards compatibility if we would now start erroring out on these, while these used to work fine with automatically picking usage 1 before). Only if one of them is a URL and the other a WC path, because we give an error message then anyway. -- Johan
Re: FreeBSD project and subversion.
On Tue, Feb 05, 2013 at 12:59:43PM +0100, Johan Corveleyn wrote: > Given what I said above, this can't be done in general (not if you > give two URLs or two wc paths, because then both synopsis 1 and 2 are > possible -- it would obviously break backwards compatibility if we > would now start erroring out on these, while these used to work fine > with automatically picking usage 1 before). Only if one of them is a > URL and the other a WC path, because we give an error message then > anyway. I think Alexey meant only the cases where we currently error out, i.e. where exactly two targets are given and one is a path and the other is a URL. I didn't realise this but there is indeed no ambiguity in allowing this syntax as a shorthand for a corresponding '--old X --new Y' diff invocation. Thanks Alexey, see http://svn.apache.org/r1442640 Making these invocations produce a diff instead of an error makes things less surprising for users.
Re: FreeBSD project and subversion.
On Mon, Feb 04, 2013 at 04:39:32PM -0800, Alexey Neyman wrote: > What adds oil to the fire is that the error message, which claims that > "Target > lists to diff may not contain both working copy paths and URL". If instead it > said that the supplied syntax is ambiguous and suggested to use --new/--old > for disambiguation, this would have saved a lot of frustration and would > eliminate the need of "svn compare" subcommand :) > > For example: > svn: Ambiguous target list (contains both work copy paths and URLs). Use > --old/--new syntax to disambiguate. Agreed. The error message wasn't very helpful. I've improved it in http://svn.apache.org/r1442645 based on your suggestion. Thanks!
Re: FreeBSD project and subversion.
On Tuesday, February 05, 2013 05:08:40 PM Stefan Sperling wrote: > On Tue, Feb 05, 2013 at 12:59:43PM +0100, Johan Corveleyn wrote: > > Given what I said above, this can't be done in general (not if you > > give two URLs or two wc paths, because then both synopsis 1 and 2 are > > possible -- it would obviously break backwards compatibility if we > > would now start erroring out on these, while these used to work fine > > with automatically picking usage 1 before). Only if one of them is a > > URL and the other a WC path, because we give an error message then > > anyway. > > I think Alexey meant only the cases where we currently error out, i.e. where > exactly two targets are given and one is a path and the other is a URL. > > I didn't realise this but there is indeed no ambiguity in allowing this > syntax as a shorthand for a corresponding '--old X --new Y' diff invocation. > > Thanks Alexey, see http://svn.apache.org/r1442640 > Making these invocations produce a diff instead of an error makes things > less surprising for users. Thanks! There is one more weird issue with svn diff, see the script below. The issue is that "--old=A --new=B" is not opposite of "--old=B --new=A". I don't know if it is a bug or another ambuguity I am not aware of :) Here is the script: [[[ #!/bin/bash REPO=/tmp/foo WC=/tmp/foo.wc rm -rf $REPO $WC svnadmin create $REPO svn co -q file://$REPO $WC cd $WC echo r1 > a svn add -q a svn ci -q -m R1 echo r2 > a svn ci -q -m R2 svn up -q -r 1 echo new > a echo "Issue: --old=A --new=B is not opposite of --old=B --new=A" echo " Running: svn di --old=^/ --new=." svn di --old=^/ --new=. echo " Running: svn di --old=. --new=^/" svn di --old=. --new=^/ ]]] And here is the output (svn 1.7.6): [[[ Issue: --old=A --new=B is not opposite of --old=B --new=A Running: svn di --old=^/ --new=. Index: a === --- a (.../file:///tmp/foo) (revision 2) +++ a (working copy) @@ -1 +1 @@ -r2 +new Running: svn di --old=. --new=^/ Index: a === --- a (working copy) +++ a (.../file:///tmp/foo) (revision 2) @@ -1 +1 @@ -r1 +r2 ]]] Regards, Alexey.
Re: FreeBSD project and subversion.
On Tuesday, February 05, 2013 12:59:43 PM Johan Corveleyn wrote: > On Tue, Feb 5, 2013 at 1:39 AM, Alexey Neyman wrote: > > On Monday, February 04, 2013 10:17:29 PM Stefan Sperling wrote: > >> On Mon, Feb 04, 2013 at 11:54:21AM -0800, Alexey Neyman wrote: > >> > Is there a reason why it is necessary to use "the svn diff --old > >> > > >> > ^/somebranch --new ." instead of the intuitive "svn ^/somebranch ."? > >> > >> Would "svn diff ^/somebranch ." be synopsis 1? > >> > >> svn diff -rN:M ^/somebranch@HEAD .@HEAD > > > > It cannot be "synopsis 1", as its description states that "TARGETs may be > > all working copy paths or all URLs". In this case, we have one of each. > > Moreover, synopsis 1 says that for URLs, -r or -c must be present - and my > > example has no -r/-c option. > > Sorry, that's not true. From 'svn help diff' of 1.7: > > diff (di): Display the differences between two revisions or paths. > usage: 1. diff [-c M | -r N[:M]] [TARGET[@REV]...] >2. diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]] \ >[PATH...] >3. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV] > > So for usage 1 the -c and -r are optional. You didn't quote the second part of 'svn help diff' description of synopsis 1. Here it is: 1. Display the changes made to TARGETs as they are seen in REV between two revisions. TARGETs may be all working copy paths or all URLs. If TARGETs are working copy paths, N defaults to BASE and M to the working copy; if URLs, N must be specified and M defaults to HEAD. The '-c M' option is equivalent to '-r N:M' where N = M-1. Using '-c -M' does the reverse: '-r M:N' where N = M-1. If you read it, you'll see that (a) Mix of URLs and paths are not allowed for this synopsis (b) For URLs, either -r or -c must be provided Regards, Alexey. y.
Re: FreeBSD project and subversion.
On Tue, Feb 05, 2013 at 09:19:19AM -0800, Alexey Neyman wrote: > There is one more weird issue with svn diff, see the script below. The issue > is that "--old=A --new=B" is not opposite of "--old=B --new=A". I don't know > if it is a bug or another ambuguity I am not aware of :) > > Here is the script: > [[[ > #!/bin/bash > > REPO=/tmp/foo > WC=/tmp/foo.wc > > rm -rf $REPO $WC > svnadmin create $REPO > svn co -q file://$REPO $WC > cd $WC > > echo r1 > a > svn add -q a > svn ci -q -m R1 > echo r2 > a > svn ci -q -m R2 > svn up -q -r 1 > echo new > a > echo "Issue: --old=A --new=B is not opposite of --old=B --new=A" > echo " Running: svn di --old=^/ --new=." > svn di --old=^/ --new=. > echo " Running: svn di --old=. --new=^/" > svn di --old=. --new=^/ > ]]] > > And here is the output (svn 1.7.6): > [[[ > Issue: --old=A --new=B is not opposite of --old=B --new=A > Running: svn di --old=^/ --new=. > Index: a > === > --- a (.../file:///tmp/foo) (revision 2) > +++ a (working copy) > @@ -1 +1 @@ > -r2 > +new > Running: svn di --old=. --new=^/ > Index: a > === > --- a (working copy) > +++ a (.../file:///tmp/foo) (revision 2) > @@ -1 +1 @@ > -r1 > +r2 > ]]] > > Regards, > Alexey. I can reproduce this with a trunk build. Can you please file an issue for this? I'm not going to get to this right away. Thanks!
Re: data encryption
Thanks, I guess my question wasn't so clear. I was asking for something or a suggestion on how to encrypt data from Subversion. Also, can anyone give me any tips or suggestion on how to set up ldap authentication for Subversion ? On Tuesday, February 5, 2013 1:15:53 AM UTC-6, Thorsten Schöning wrote: > Guten Tag Hector Magnanao, > am Montag, 4. Februar 2013 um 22:24 schrieben Sie: > > > Hi, I have installed Subversion and Ubersvn on a windows 2008 > > server - 64 bit machine. How do you set up data encryption on > Subversion ? > > As said, Subversion itself doesn't provide data encryption, but you > can use what Windows provides, like EFS or BitLocker, whatever you > need. > > 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: FreeBSD project and subversion.
On 02/05/2013 01:14 PM, Stefan Sperling wrote: On Tue, Feb 05, 2013 at 09:19:19AM -0800, Alexey Neyman wrote: There is one more weird issue with svn diff, see the script below. The issue is that "--old=A --new=B" is not opposite of "--old=B --new=A". I don't know if it is a bug or another ambuguity I am not aware of :) Here is the script: [[[ #!/bin/bash REPO=/tmp/foo WC=/tmp/foo.wc rm -rf $REPO $WC svnadmin create $REPO svn co -q file://$REPO $WC cd $WC echo r1 > a svn add -q a svn ci -q -m R1 echo r2 > a svn ci -q -m R2 svn up -q -r 1 echo new > a echo "Issue: --old=A --new=B is not opposite of --old=B --new=A" echo " Running: svn di --old=^/ --new=." svn di --old=^/ --new=. echo " Running: svn di --old=. --new=^/" svn di --old=. --new=^/ ]]] And here is the output (svn 1.7.6): [[[ Issue: --old=A --new=B is not opposite of --old=B --new=A Running: svn di --old=^/ --new=. Index: a === --- a (.../file:///tmp/foo) (revision 2) +++ a (working copy) @@ -1 +1 @@ -r2 +new Running: svn di --old=. --new=^/ Index: a === --- a (working copy) +++ a (.../file:///tmp/foo) (revision 2) @@ -1 +1 @@ -r1 +r2 ]]] Regards, Alexey. I can reproduce this with a trunk build. Can you please file an issue for this? I'm not going to get to this right away. Thanks! Here is the issue that I see: The --old=. get's the workspace version of ., but --new get's the non-changed version of /. So, I believe it is comparing "r1" with the r2 contents of "r2" and not comparing both workspace versions. RevContents 1r1 2r2 2* new 2* only get's referenced when it is in the --old position, 2 get's used when its in the --new position. Please correct me if I'm wrong about this, but that is what seems to be a logical reasoning behind that behavior. Lathan
Re: FreeBSD project and subversion.
On Tue, Feb 5, 2013 at 5:08 PM, Stefan Sperling wrote: > On Tue, Feb 05, 2013 at 12:59:43PM +0100, Johan Corveleyn wrote: >> Given what I said above, this can't be done in general (not if you >> give two URLs or two wc paths, because then both synopsis 1 and 2 are >> possible -- it would obviously break backwards compatibility if we >> would now start erroring out on these, while these used to work fine >> with automatically picking usage 1 before). Only if one of them is a >> URL and the other a WC path, because we give an error message then >> anyway. > > I think Alexey meant only the cases where we currently error out, i.e. where > exactly two targets are given and one is a path and the other is a URL. > > I didn't realise this but there is indeed no ambiguity in allowing this > syntax as a shorthand for a corresponding '--old X --new Y' diff invocation. > > Thanks Alexey, see http://svn.apache.org/r1442640 > Making these invocations produce a diff instead of an error makes things > less surprising for users. Hmm, okay, but I would have preferred some more discussion before you implemented this. It's not clear to me that this decreases the surprises. I can perfectly imagine just as many questions being asked on users@ with the question: "Why does 'svn diff left.txt right.txt' give me an empty diff, while 'svn diff ^/left.txt right.txt' does the right thing?" I think it would be better to consistently point users to the --old/--new syntax, so as to educate users more (so I'm okay with the change in the error message), not hide it even more from them. Speaking of the error message: On Tue, Feb 5, 2013 at 5:24 PM, Stefan Sperling wrote: > On Mon, Feb 04, 2013 at 04:39:32PM -0800, Alexey Neyman wrote: >> What adds oil to the fire is that the error message, which claims that >> "Target >> lists to diff may not contain both working copy paths and URL". If instead it >> said that the supplied syntax is ambiguous and suggested to use --new/--old >> for disambiguation, this would have saved a lot of frustration and would >> eliminate the need of "svn compare" subcommand :) >> >> For example: >> svn: Ambiguous target list (contains both work copy paths and URLs). Use >> --old/--new syntax to disambiguate. > > Agreed. The error message wasn't very helpful. > I've improved it in http://svn.apache.org/r1442645 based on your suggestion. > Thanks! How is this useful after r1442640? Seems to me we should either improve the error message (which would be my preferred option) *or* make 'svn diff' handle these automatically as a shorthand syntax (hence no error message). But not both. Or am I missing something? -- Johan
RE: How do I refactor without confusing Subversion?[SEC=UNCLASSIFIED]
UNCLASSIFIED In any case, its probably about time to upgrade. (-: -Original Message- From: Daniel Shahaf [mailto:danie...@apache.org] Sent: Thursday, 31 January 2013 6:24 PM To: Thamm, Russell Cc: users@subversion.apache.org; Andreas Tscharner Subject: Re: How do I refactor without confusing Subversion?[SEC=UNCLASSIFIED] We're working on better move/rename support for 1.8, but I'm not sure whether your specific use-case will already be fixed in 1.8 or not. Maybe one of the other devs can comment on that. Thamm, Russell wrote on Wed, Jan 30, 2013 at 13:39:38 +1030: > UNCLASSIFIED > > Thanks Andreas, > > This seems like a significant limitation with subversion. > > Cheers > Russell Thamm > > > -Original Message- > From: Andreas Tscharner [mailto:andreas.tschar...@metromec.ch] > Sent: Wednesday, 30 January 2013 12:55 AM > To: Thamm, Russell; users@subversion.apache.org > Subject: RE: How do I refactor without confusing Subversion? > [SEC=UNCLASSIFIED] > > > [snip] > > When I attempt to merge the trunk into the branch, I get a whole > > bunch > > > of "Skipped missing target" errors. I only get these errors on moved > > files. It seems that subversion is > > [snip] > > Have I done something wrong or is this a limitation with subversion? > > This is a limitation of subversion. Subversion does not track > renames/moves for merging. IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email.
Re: data encryption
Guten Tag Hector Magnanao, am Dienstag, 5. Februar 2013 um 19:29 schrieben Sie: > Thanks, I guess my question wasn't so clear. I was asking for > something or a suggestion on how to encrypt data from Subversion. This doesn't sound more clearly to more than the question before. :-/ > Also, can anyone give me any tips or suggestion on how to set up > ldap authentication for Subversion ? You should start a new thread for this and search the web, there are a lot of of hits. 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: FreeBSD project and subversion.
On Tuesday, February 05, 2013 01:55:20 PM Lathan Bidwell wrote: > On 02/05/2013 01:14 PM, Stefan Sperling wrote: > > On Tue, Feb 05, 2013 at 09:19:19AM -0800, Alexey Neyman wrote: > >> There is one more weird issue with svn diff, see the script below. The > >> issue is that "--old=A --new=B" is not opposite of "--old=B --new=A". I > >> don't know if it is a bug or another ambuguity I am not aware of :) > >> > >> Here is the script: > >> [[[ > >> #!/bin/bash > >> > >> REPO=/tmp/foo > >> WC=/tmp/foo.wc > >> > >> rm -rf $REPO $WC > >> svnadmin create $REPO > >> svn co -q file://$REPO $WC > >> cd $WC > >> > >> echo r1 > a > >> svn add -q a > >> svn ci -q -m R1 > >> echo r2 > a > >> svn ci -q -m R2 > >> svn up -q -r 1 > >> echo new > a > >> echo "Issue: --old=A --new=B is not opposite of --old=B --new=A" > >> echo " Running: svn di --old=^/ --new=." > >> svn di --old=^/ --new=. > >> echo " Running: svn di --old=. --new=^/" > >> svn di --old=. --new=^/ > >> ]]] > >> > >> And here is the output (svn 1.7.6): > >> [[[ > >> Issue: --old=A --new=B is not opposite of --old=B --new=A > >> > >>Running: svn di --old=^/ --new=. > >> > >> Index: a > >> === > >> --- a (.../file:///tmp/foo) (revision 2) > >> +++ a (working copy) > >> @@ -1 +1 @@ > >> -r2 > >> +new > >> > >>Running: svn di --old=. --new=^/ > >> > >> Index: a > >> === > >> --- a (working copy) > >> +++ a (.../file:///tmp/foo) (revision 2) > >> @@ -1 +1 @@ > >> -r1 > >> +r2 > >> ]]] > >> > >> Regards, > >> Alexey. > > > > I can reproduce this with a trunk build. Can you please file an issue > > for this? I'm not going to get to this right away. Thanks! > > Here is the issue that I see: > > The --old=. get's the workspace version of ., but --new get's the > non-changed version of /. > > So, I believe it is comparing "r1" with the r2 contents of "r2" and not > comparing both workspace versions. > > RevContents > 1r1 > 2r2 > 2* new > > 2* only get's referenced when it is in the --old position, > 2 get's used when its in the --new position. > > Please correct me if I'm wrong about this, but that is what seems to be > a logical reasoning behind that behavior. First, it is just the opposite: 2* gets referenced when it is in the --new, not --old position. Second, it is not the reasoning (why it behaves so) but rather a description of current behavior, which I think was rather obvious from the example script. The reason for this behavior is that the code in diff-cmd.c makes the following defaults for the old/new revisions: if (opt_state->start_revision.kind == svn_opt_revision_unspecified) opt_state->start_revision.kind = svn_path_is_url(old_target) ? svn_opt_revision_head : svn_opt_revision_base; if (opt_state->end_revision.kind == svn_opt_revision_unspecified) opt_state->end_revision.kind = svn_path_is_url(new_target) ? svn_opt_revision_head : svn_opt_revision_working; These defaults make some sense, given that new target is optional and defaults to old target if not specified. If new target is specified, and is different from from old target, I am not so sure if it makes sense. Note that there is a special case if both old/new targets are WC paths - in that case, both old and new targets default to svn_opt_revision_working. So, $ svn diff --old=foo --new=bar will compare modified version of 'foo' against modified version of 'bar' [*], but $ svn diff --old=foo --new=^/bar would compare base version of 'foo' against HEAD version of 'bar. Does it make sense? I would say, if both old and new are specified, old target's revision should default to 'working' as well. Problem is further aggravated since there is no commandline alias to request svn_opt_revision_working setting from the command line: only 'head', 'prev', 'base' and 'committed' are currently available. Hence, it is not possible to request the exact opposite of the patch using -rN:M syntax if one of the -- old/--new targets is a working copy path. Is there a reason why 'working' is not parsed by revision_from_word()? Also note that 'svn help diff' does not describe revision defaults for synopsis 2 (and the default is different from synopsis 1, which requires old revision to be specified for URLs). PS. Stephan apparently made 'working' revision as default in his check-in (r1442640) at least for the short-hand form, but Julian Foad, "optimizing the logic" in r1442659 and r1442676, switched it back to be the same as --old/-- new logic. PPS. If agreed to suggested change of default, the patch is attached. [[[ Make svn diff --old=.. --new=.. default to WORKING revision for old target if new target is explicitly specified. * subversion/svn/diff-cmd.c (svn_cl__diff) Change defaults as described and simplify the logic. ]]] Regards, Alexey.Index: su
Re: data encryption
On 2/5/2013 4:09 PM, Thorsten Schöning wrote: Guten Tag Hector Magnanao, am Dienstag, 5. Februar 2013 um 19:29 schrieben Sie: Thanks, I guess my question wasn't so clear. I was asking for something or a suggestion on how to encrypt data from Subversion. This doesn't sound more clearly to more than the question before. :-/ I think he means he wants to know how to encrypt data transmitted between the Subversion server and the client... in which case, check the documentation on how to set up access to the repository through SSH and/or HTTPS. http://svnbook.red-bean.com/en/1.7/svn.serverconfig.choosing.html#svn.serverconfig.choosing.svn-ssh
Re: FreeBSD project and subversion.
On Tue, Feb 05, 2013 at 09:18:33PM +0100, Johan Corveleyn wrote: > Hmm, okay, but I would have preferred some more discussion before you > implemented this. It's not clear to me that this decreases the > surprises. I can perfectly imagine just as many questions being asked > on users@ with the question: "Why does 'svn diff left.txt right.txt' > give me an empty diff, while 'svn diff ^/left.txt right.txt' does the > right thing?" > > I think it would be better to consistently point users to the > --old/--new syntax, so as to educate users more (so I'm okay with the > change in the error message), not hide it even more from them. Well, the point that convinced me was that previously 'svn diff' raised an error in the case of 'svn diff ^/left.txt right.txt'. That's clearly intended to be a comparison between a URL and a path, which the diff code already supports. So I think the diff code should just show an appropriate diff. I don't see how people could be conflating a URL->WC or WC->URL diff with a WC->WC diff. BTW, I'm thinking about adding more shortcuts: svn diff UNVERSIONED-PATH WCPATH svn diff WCPATH UNVERSIONED-PATH svn diff UNVERSIONED-PATH1 UNVERSIONED-PATH2 All of which are supported by 'svn diff --old=X --new=Y' (in 1.8-to-be, not in 1.7), but not by plain 'svn diff'. The --old --new syntax is specific to Subversion. Many users who are accustomed to "standard" diff commands will not try using --old and --new (unless they've taken the time to read 'svn help diff', of course, which apparently is too much time to ask from some users ;) That said, if you'd rather just print the error message instead, that's fine with me, too. I don't care strongly enough about this to the point where I'd say that we _must_ make this change to 'svn diff'. It's been committed, but that doesn't mean that this has to be in 1.8.0 at all costs. > Speaking of the error message: > How is this useful after r1442640? Seems to me we should either > improve the error message (which would be my preferred option) *or* > make 'svn diff' handle these automatically as a shorthand syntax > (hence no error message). But not both. > > Or am I missing something? The error message is triggered by an invocation like: svn diff -c42 foo ^/trunk bar Which is clearly invalid usage according to 'svn help diff'.
Re: Missing file prevents submitting unrelated changelists
On Mon, 2013-01-28 at 21:56 +0100, Johan Corveleyn wrote: > On Mon, Jan 28, 2013 at 5:31 PM, Nick wrote: > > On Mon, 2013-01-28 at 18:03 +0200, Daniel Shahaf wrote: > >> I see, perhaps I misread your initial script. I wonder whether > >> $ svn ci --cl "Add a and b" a b > >> works... (but no time to test right now :( ) > > > > That works--files a and b are submitted despite file c missing. > > > > Should I open a bug on this now, or wait for one of the developers to > > confirm it first? I'm not in a rush, so whatever works best for the > > devs. > > Sounds like a bug to me. This one is somewhat similar (though not the same): > > http://subversion.tigris.org/issues/show_bug.cgi?id=3484 (Submitting a > changelist while obstructed item exists) Right, similar in nature, but different in specifics. Daniel: Do you want to confirm before I open a bug? Nick
Re: FreeBSD project and subversion.
On Wed, Feb 6, 2013 at 12:07 AM, Stefan Sperling wrote: > On Tue, Feb 05, 2013 at 09:18:33PM +0100, Johan Corveleyn wrote: >> Hmm, okay, but I would have preferred some more discussion before you >> implemented this. It's not clear to me that this decreases the >> surprises. I can perfectly imagine just as many questions being asked >> on users@ with the question: "Why does 'svn diff left.txt right.txt' >> give me an empty diff, while 'svn diff ^/left.txt right.txt' does the >> right thing?" >> >> I think it would be better to consistently point users to the >> --old/--new syntax, so as to educate users more (so I'm okay with the >> change in the error message), not hide it even more from them. > > Well, the point that convinced me was that previously 'svn diff' raised > an error in the case of 'svn diff ^/left.txt right.txt'. > That's clearly intended to be a comparison between a URL and a path, > which the diff code already supports. So I think the diff code should > just show an appropriate diff. I don't see how people could be conflating > a URL->WC or WC->URL diff with a WC->WC diff. > > BTW, I'm thinking about adding more shortcuts: > > svn diff UNVERSIONED-PATH WCPATH > svn diff WCPATH UNVERSIONED-PATH > svn diff UNVERSIONED-PATH1 UNVERSIONED-PATH2 > > All of which are supported by 'svn diff --old=X --new=Y' (in 1.8-to-be, > not in 1.7), but not by plain 'svn diff'. > > The --old --new syntax is specific to Subversion. Many users who are > accustomed to "standard" diff commands will not try using --old and --new > (unless they've taken the time to read 'svn help diff', of course, which > apparently is too much time to ask from some users ;) > > That said, if you'd rather just print the error message instead, that's > fine with me, too. I don't care strongly enough about this to the point > where I'd say that we _must_ make this change to 'svn diff'. It's been > committed, but that doesn't mean that this has to be in 1.8.0 at all costs. Nah, it's fine, I think I'm starting to get convinced ;-). But it's still a pity that there is no relief (at least I don't see any) for confusion around the fact that 'svn diff WC-PATH1 WC-PATH2' doesn't diff WC-PATH1 and WC-PATH2 against each other. The shorthands with the unversioned paths are quite nice I think, but there is an additional risk of confusion: 'svn diff UNVERSIONED-PATH1 UNVERSIONED-PATH2' will mean something totally different than 'svn diff WC-PATH1 WC-PATH2' (even though they could both refer to the same local files, but the commands are separated by an invocation of 'svn add'). >> Speaking of the error message: > >> How is this useful after r1442640? Seems to me we should either >> improve the error message (which would be my preferred option) *or* >> make 'svn diff' handle these automatically as a shorthand syntax >> (hence no error message). But not both. >> >> Or am I missing something? > > The error message is triggered by an invocation like: > > svn diff -c42 foo ^/trunk bar > > Which is clearly invalid usage according to 'svn help diff'. Yes, but in this case the user gives 3 targets, so he clearly couldn't have meant one of the shorthand syntaxes, right? -- Johan
Re: Missing file prevents submitting unrelated changelists
On Tue, Feb 05, 2013 at 06:23:10PM -0500, Nick wrote: > On Mon, 2013-01-28 at 21:56 +0100, Johan Corveleyn wrote: > > Sounds like a bug to me. This one is somewhat similar (though not the same): > > > > http://subversion.tigris.org/issues/show_bug.cgi?id=3484 (Submitting a > > changelist while obstructed item exists) > > Right, similar in nature, but different in specifics. > > Daniel: Do you want to confirm before I open a bug? > > Nick I agree it's a bug. The state of items not in the changelist shouldn't affect commit of items in the changelist. Please file a bug so that someone will take a look at it eventually! Thanks :) Please don't forget to include a link to this thread in the issue (either in the 'URL' field of the issue or simply in a comment attached to the issue).
RE: FreeBSD project and subversion.
> -Original Message- > From: Stefan Sperling [mailto:s...@apache.org] > Sent: woensdag 6 februari 2013 00:08 > To: Johan Corveleyn > Cc: Alexey Neyman; users@subversion.apache.org; Alfred Perlstein > Subject: Re: FreeBSD project and subversion. > > On Tue, Feb 05, 2013 at 09:18:33PM +0100, Johan Corveleyn wrote: > > Hmm, okay, but I would have preferred some more discussion before you > > implemented this. It's not clear to me that this decreases the > > surprises. I can perfectly imagine just as many questions being asked > > on users@ with the question: "Why does 'svn diff left.txt right.txt' > > give me an empty diff, while 'svn diff ^/left.txt right.txt' does the > > right thing?" > > > > I think it would be better to consistently point users to the > > --old/--new syntax, so as to educate users more (so I'm okay with the > > change in the error message), not hide it even more from them. > > Well, the point that convinced me was that previously 'svn diff' raised > an error in the case of 'svn diff ^/left.txt right.txt'. > That's clearly intended to be a comparison between a URL and a path, > which the diff code already supports. So I think the diff code should > just show an appropriate diff. I don't see how people could be conflating > a URL->WC or WC->URL diff with a WC->WC diff. > > BTW, I'm thinking about adding more shortcuts: > > svn diff UNVERSIONED-PATH WCPATH > svn diff WCPATH UNVERSIONED-PATH > svn diff UNVERSIONED-PATH1 UNVERSIONED-PATH2 > > All of which are supported by 'svn diff --old=X --new=Y' (in 1.8-to-be, > not in 1.7), but not by plain 'svn diff'. I'm not sure if I like these variants with unversioned paths. This might make users think that these paths are versioned and without warning who wouldn't expect that? The new unversioned/arbitrary diff is nice in specific situations, but it shouldn't' break the normal cases where 'svn diff *' would do one thing completely differently if it happens to match exactly two files, where one is versioned and one is not, or both are unversioned. If we want something like that we should support that with a flag like --unversioned (better name suggestions welcome) I really like the url vs path diff changes though. Bert
Re: FreeBSD project and subversion.
On Wed, Feb 06, 2013 at 12:30:05AM +0100, Johan Corveleyn wrote: > Nah, it's fine, I think I'm starting to get convinced ;-). But it's > still a pity that there is no relief (at least I don't see any) for > confusion around the fact that 'svn diff WC-PATH1 WC-PATH2' doesn't > diff WC-PATH1 and WC-PATH2 against each other. I agree very much that it is rather confusing that svn diff WC-PATH1 WC-PATH1 does something else than: svn diff --old WC-PATH1 --new WC-PATH2 However, I think that the current help text makes the difference clear, if only the user cares to read it. As long as the documentation is clear enough, such subtleties are fine with me. I mean that I'll probably be able to remember them and explain them to people -- which is what I'm supposed to be doing at $DAYJOB -- hence that's why I'm fine with it :) Joke aside, I'm not sure if there is a really good way to resolve these ambiguities. I don't really like that fact that we've got these --old and --new options in the first place. It seems like a crutch for a lack of a better syntax that can express all use cases equally well without being rather weird and uncommon. But since the syntax is present in releases we have to keep supporting it... > The shorthands with the unversioned paths are quite nice I think, but > there is an additional risk of confusion: 'svn diff UNVERSIONED-PATH1 > UNVERSIONED-PATH2' will mean something totally different than 'svn > diff WC-PATH1 WC-PATH2' (even though they could both refer to the same > local files, but the commands are separated by an invocation of 'svn > add'). Yeah, it is going to make things even more confusing, of course! But only for those who type the diff command and expect a different result than they're getting :) > > The error message is triggered by an invocation like: > > > > svn diff -c42 foo ^/trunk bar > > > > Which is clearly invalid usage according to 'svn help diff'. > > Yes, but in this case the user gives 3 targets, so he clearly couldn't > have meant one of the shorthand syntaxes, right? Only if the user did not understand the (somewhat obscure by nature) help text... The warning is really meant to get people who provide nonsense arguments to read 'svn help diff'.
Re: FreeBSD project and subversion.
On 06.02.2013 00:58, Stefan Sperling wrote: > Joke aside, I'm not sure if there is a really good way to resolve > these ambiguities. I don't really like that fact that we've got these > --old and --new options in the first place. It seems like a crutch for > a lack of a better syntax that can express all use cases equally well > without being rather weird and uncommon. But since the syntax is > present in releases we have to keep supporting it... I agree about not liking --old and --new. But we went through exactly the same arguments back in the day when they were invented, and the argument that won was against confusing users with the fact that: $ svn diff param1 param2 could have two completely different meanings based on some magic involved in interpreted the parameters, whereas: $ svn diff param1 or $ svn diff param1 param2 param3 can each have only one meaning. I think the only way out of adding --new and --old, given the premise that user confusion was absolutely evil (which I agreed with and still do), would have been to have only two forms of "svn diff" -- the one-parameter form that produces a historical diff, and the two-parameter form which would produce a diff between the two targets. However, that was seen as insufficient, given the (then) goal of CVS feature parity, and simple usability required that we had a way to produce historical diffs for N targets (where N >= 1). Given all the above, I think we should find a way to warn users -- with a one-line note in the header of the diff output, for example? -- about the cases where the two-parameter diff could be ambiguous (which, I believe, is when both parametrs are WC paths or URLs); and further, when any of the paths are unversioned. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
