Transaction and revision numbers
Is there a special format of a transaction number? I would like to write a method in perl that gets a number, either transaction or revision, and then adds the correct --revision or --transaction parameter (for the svnlook command). So if there is a special format for a transaction number I can use a regular expression to check it. Thanks Giulio Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
Re: SSL handshake failed: SSL error: A TLS warning alert has been received.
On Wed, 2010-08-18 at 02:06 -0400, Nico Kadel-Garcia wrote: On Wed, Aug 11, 2010 at 10:24 AM, Gero wrote: > > Hi, > > > > After moving to a new system (Kubuntu Hardy -> Lucid) I can no longer access > > an SVN repository: > > > > $ svn update > > svn: OPTIONS of 'https://example.com/path/to/svn/trunk': SSL handshake > > failed: SSL error: A TLS warning alert has been received. > > (https://example.com) > > But 'svn info 'https://example.com/path/to/svn/trunk works? What about > doing a clean checkout to a new location? 'svn info' with no arguments works and shows info about the repository in question. 'svn info ', however, does not work, with the same error message as above. A clean checkout doesn't work either. There is an Ubuntu bug report about Subversion not playing with the latest libneon nor libneon-gnutls. Apparently, libneon now reports more SSL problems that Subversion should ignore, but doesn't. Is this something that could be fixed by the Subversion team? Thanks, Gero.
Re: SSL handshake failed: SSL error: A TLS warning alert has been received.
Forgot the link to the Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/294648
RE: SSL handshake failed: SSL error: A TLS warning alert has been received.
> -Original Message- > From: Gero [mailto:g...@ieee.org] > Sent: maandag 6 september 2010 11:37 > To: users@subversion.apache.org > Subject: Re: SSL handshake failed: SSL error: A TLS warning alert has been > received. > > On Wed, 2010-08-18 at 02:06 -0400, Nico Kadel-Garcia wrote: > On Wed, Aug 11, 2010 at 10:24 AM, Gero wrote: > > > Hi, > > > > > > After moving to a new system (Kubuntu Hardy -> Lucid) I can no > longer access > > > an SVN repository: > > > > > > $ svn update > > > svn: OPTIONS of 'https://example.com/path/to/svn/trunk': SSL > handshake > > > failed: SSL error: A TLS warning alert has been received. > > > (https://example.com) > > > > But 'svn info 'https://example.com/path/to/svn/trunk works? What about > > doing a clean checkout to a new location? > > 'svn info' with no arguments works and shows info about the repository > in question. 'svn info ', however, does not work, with the same > error message as above. A clean checkout doesn't work either. > > There is an Ubuntu bug report about Subversion not playing with the > latest libneon nor libneon-gnutls. Apparently, libneon now reports more > SSL problems that Subversion should ignore, but doesn't. Subversion uses neon and neon uses your SSL library. Subversion doesn't use the ssl library directly. So this should be fixed either in Neon or (to restore compatibility with the older version) in the SSL library. Bert
RE: Merge problem with different users
The "merge user" is just a user account. Since we noticed that the problem described earlier only occurs when the merging is made by different users (on different user accounts), we created a new user account (called mergeuser) that all developers use for merging (and reintegration). So the users itself are still different, but they use the same account. -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Freitag, 3. September 2010 11:08 To: Ungruhe, Michael Cc: users@subversion.apache.org; Strucken, Andreas Subject: Re: Merge problem with different users On Fri, Sep 03, 2010 at 12:53:34AM -0700, Ungruhe, Michael wrote: > Hi, > > > > We noticed the following problem: > > > > We are usually working on the trunk, but for a change request we created a branch. Development continued on both, the trunk and the branch. > > Some changes were made on the trunk including the deletion of some files, all changes were committed to the trunk. > > User A wanted to merge the changes from the trunk into the branch using the "svn merge" command. Everything went fine, all updates have been recognized, the deleted files have been deleted on the branch. The merged results have been committed to the branch. > > After a while, another user (User B) wanted to merge changes made in the meantime from the trunk into the branch. > > He received the following messages for the files that have been deleted in the first merge (of User A): "Local delete, incoming delete upon merge". He marked the tree conflicts as resolved and checked in the merged version to the branch. The next time User B wanted to merge changes from the trunk to the branch, he received the same error messages for the same (deleted) files. He was not able to bring the branch to a state at which it could be reintegrated to the trunk. > > When User A tried to do the merge, everything went fine and the branch could be reintegrated to the trunk. > > After we noticed the same problem on different branches, we created a "merge user" who will be used to do the merging and reintegration as a work around. > > > > Is this a known issue or is there another way of merging etc with different users? > > We are using SVN 1.6.5 on CentOS 5 Sounds like some users didn't commmit mergeinfo correctly. What did the mergeinfo on the trunk look like after the first merge? svn propget -R -v svn:mergeinfo trunk_...@rev-of-first-merge-commit What did the mergeinfo on the branch look like after the first merge? svn propget -R -v svn:mergeinfo branch_...@rev-of-first-merge-commit What does the mergeinfo look like in all the other revisions where merges were committed? Why does your "merge user" fix the problem? Maybe that user is doing merges differently than some of the developers did? Stefan
Re: Transaction and revision numbers
On Mon, Sep 6, 2010 at 7:29 PM, Giulio Troccoli < giulio.trocc...@uk.linedata.com> wrote: > Is there a special format of a transaction number? > > I would like to write a method in perl that gets a number, either > transaction or revision, and then adds the correct --revision or > --transaction parameter (for the svnlook command). So if there is a special > format for a transaction number I can use a regular expression to check it. > The difference between a transaction and revision number depends purely on context. AFAIK, the only time a transaction number is available is within a pre-commit hook - once the transaction has been committed, it's a revision number. What context would your script be run in? Cheers, Daniel B.
RE: Transaction and revision numbers
Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 From: Daniel Becroft [mailto:djcbecr...@gmail.com] Sent: 06 September 2010 10:52 To: Giulio Troccoli Cc: users@subversion.apache.org Subject: Re: Transaction and revision numbers On Mon, Sep 6, 2010 at 7:29 PM, Giulio Troccoli wrote: Is there a special format of a transaction number? I would like to write a method in perl that gets a number, either transaction or revision, and then adds the correct --revision or --transaction parameter (for the svnlook command). So if there is a special format for a transaction number I can use a regular expression to check it. The difference between a transaction and revision number depends purely on context. AFAIK, the only time a transaction number is available is within a pre-commit hook - once the transaction has been committed, it's a revision number. What context would your script be run in? Cheers, Daniel B. The class will be used by both the pre- and post-commit hooks, hence the need to distinguish between transaction or revision. And I would like to do it by just looking at the transaction/revision number. I think transactions are in the format of 999-9 (where 9 is any single number) while revisions are in the format 9. If that's true, then I can check for the dash and I'm done. Can anyone confirm it to me? Giulio
Re: Transaction and revision numbers
On Mon, Sep 6, 2010 at 7:57 PM, Giulio Troccoli < giulio.trocc...@uk.linedata.com> wrote: > > > > > > > Linedata Limited > Registered Office: 85 Gracechurch St., London, EC3V 0AA > Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 > > > > > >From: Daniel Becroft [mailto:djcbecr...@gmail.com] >Sent: 06 September 2010 10:52 >To: Giulio Troccoli >Cc: users@subversion.apache.org >Subject: Re: Transaction and revision numbers > > >On Mon, Sep 6, 2010 at 7:29 PM, Giulio Troccoli < > giulio.trocc...@uk.linedata.com> wrote: > > >Is there a special format of a transaction number? > >I would like to write a method in perl that gets a number, > either transaction or revision, and then adds the correct --revision or > --transaction parameter (for the svnlook command). So if there is a special > format for a transaction number I can use a regular expression to check it. > > > >The difference between a transaction and revision number depends > purely on context. AFAIK, the only time a transaction number is available is > within a pre-commit hook - once the transaction has been committed, it's a > revision number. > >What context would your script be run in? > >Cheers, >Daniel B. > > > The class will be used by both the pre- and post-commit hooks, hence the > need to distinguish between transaction or revision. And I would like to do > it by just looking at the transaction/revision number. > I think transactions are in the format of 999-9 (where 9 is any single > number) while revisions are in the format 9. If that's true, then I can > check for the dash and I'm done. Can anyone confirm it to me? Again, I think you would be better using it based on context, rather than the actual string format (this could change down the track). Something like this would be the simplest (but not the best): PerformAction(repository_uuid, transaction_Id, revision_Id) - for pre-commit hook, only populate the first two parameters - for post-commit hook, populate the first and third parameters Cheers, Daniel B.
Re: Transaction and revision numbers
On Monday 06 Sep 2010, Giulio Troccoli wrote: > > > The class will be used by both the pre- and post-commit hooks, hence the > need to distinguish between transaction or revision. And I would like to do > it by just looking at the transaction/revision number. > > I think transactions are in the format of 999-9 (where 9 is any single > number) while revisions are in the format 9. If that's true, then I can > check for the dash and I'm done. Can anyone confirm it to me? > > Giulio I'm not sure about the transaction number always having a dash but another alternative approach could be to check the script name. So long as the script is a link from post-commit/pre-commit then it's name will be different and can be used to distinguish the two uses. I've used this trick so that one shell script logs changes from a post-commit, post-revprop-change (which also has different parameters) and CVS. -- __ Sword Ciboodle is the trading name of ciboodle Limited (a company registered in Scotland with registered number SC143434 and whose registered office is at India of Inchinnan, Renfrewshire, UK, PA4 9LH) which is part of the Sword Group of companies. This email (and any attachments) is intended for the named recipient(s) and is private and confidential. If it is not for you, please inform us and then delete it. If you are not the intended recipient(s), the use, disclosure, copying or distribution of any information contained within this email is prohibited. Messages to and from us may be monitored. If the content is not about the business of the Sword Group then the message is neither from nor sanctioned by us. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this email or any attachment. __
RE: Transaction and revision numbers
>
Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
-Original Message-
> From: Campbell Allan [mailto:campbell.al...@sword-ciboodle.com]
> Sent: 06 September 2010 11:40
> To: users@subversion.apache.org
> Cc: Giulio Troccoli; 'Daniel Becroft'
> Subject: Re: Transaction and revision numbers
>
> On Monday 06 Sep 2010, Giulio Troccoli wrote:
> >
> >
> > The class will be used by both the pre- and post-commit
> hooks, hence
> > the need to distinguish between transaction or revision.
> And I would
> > like to do it by just looking at the transaction/revision number.
> >
> > I think transactions are in the format of 999-9 (where 9 is any
> > single
> > number) while revisions are in the format 9. If that's
> true, then
> > I can check for the dash and I'm done. Can anyone confirm it to me?
> >
> > Giulio
>
> I'm not sure about the transaction number always having a
> dash but another alternative approach could be to check the
> script name. So long as the script is a link from
> post-commit/pre-commit then it's name will be different and
> can be used to distinguish the two uses. I've used this trick
> so that one shell script logs changes from a post-commit,
> post-revprop-change (which also has different parameters) and CVS.
>
I don't understand what you're saying here. However I have decided to follow
another approach.
The calling script will pass a hash specifying either the transaction or the
revision. Something like
SVN::get_author({ revision => $rev }) or SVN::get_author({ transaction => $txn
})
So, get_author will know what to do.
Giulio
Re: Transaction and revision numbers
On Monday 06 Sep 2010, Giulio Troccoli wrote:
> Linedata Limited
> Registered Office: 85 Gracechurch St., London, EC3V 0AA
> Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
>
> -Original Message-
>
> > From: Campbell Allan [mailto:campbell.al...@sword-ciboodle.com]
> > Sent: 06 September 2010 11:40
> > To: users@subversion.apache.org
> > Cc: Giulio Troccoli; 'Daniel Becroft'
> > Subject: Re: Transaction and revision numbers
> >
> > On Monday 06 Sep 2010, Giulio Troccoli wrote:
> > > The class will be used by both the pre- and post-commit
> >
> > hooks, hence
> >
> > > the need to distinguish between transaction or revision.
> >
> > And I would
> >
> > > like to do it by just looking at the transaction/revision number.
> > >
> > > I think transactions are in the format of 999-9 (where 9 is any
> > > single
> > > number) while revisions are in the format 9. If that's
> >
> > true, then
> >
> > > I can check for the dash and I'm done. Can anyone confirm it to me?
> > >
> > > Giulio
> >
> > I'm not sure about the transaction number always having a
> > dash but another alternative approach could be to check the
> > script name. So long as the script is a link from
> > post-commit/pre-commit then it's name will be different and
> > can be used to distinguish the two uses. I've used this trick
> > so that one shell script logs changes from a post-commit,
> > post-revprop-change (which also has different parameters) and CVS.
>
> I don't understand what you're saying here. However I have decided to
> follow another approach.
>
> The calling script will pass a hash specifying either the transaction or
> the revision. Something like
>
> SVN::get_author({ revision => $rev }) or SVN::get_author({ transaction =>
> $txn })
>
> So, get_author will know what to do.
>
> Giulio
That's a good idea. Just to clarify my approach, perhaps an example is better.
Imagine the following script was softlinked from the pre and post commit hook
scripts:
#!/usr/bin/perl
if ( $0 =~ /(^|\/)post-commit$/ ) {
print "post-commit actions\n";
}
elsif ( $0 =~ /(^|\/)pre-commit$/ ) {
print "pre-commit actions\n";
}
then when invoked $0 will contain either pre-commit or post-commit. It's a
feature of links that some unix utilities make use of so there can be a
single binary that has multiple modes of operation change which it does
depending on the name it was invoked as. For example bunzip2 is a link to
bzip2 but implies the -d option. Unfortunately I only know of it working on
unix systems.
Campbell
--
__
Sword Ciboodle is the trading name of ciboodle Limited (a company
registered in Scotland with registered number SC143434 and whose
registered office is at India of Inchinnan, Renfrewshire, UK,
PA4 9LH) which is part of the Sword Group of companies.
This email (and any attachments) is intended for the named
recipient(s) and is private and confidential. If it is not for you,
please inform us and then delete it. If you are not the intended
recipient(s), the use, disclosure, copying or distribution of any
information contained within this email is prohibited. Messages to
and from us may be monitored. If the content is not about the
business of the Sword Group then the message is neither from nor
sanctioned by us.
Internet communications are not secure. You should scan this
message and any attachments for viruses. Under no circumstances
do we accept liability for any loss or damage which may result from
your receipt of this email or any attachment.
__
Re: Merge problem with different users
On Mon, Sep 06, 2010 at 02:44:30AM -0700, Ungruhe, Michael wrote: > The "merge user" is just a user account. Since we noticed that the > problem described earlier only occurs when the merging is made by > different users (on different user accounts), we created a new user > account (called mergeuser) that all developers use for merging (and > reintegration). So the users itself are still different, but they use > the same account. Ok, but do you have answers to my questions regarding mergeinfo? I'm trying to figure out where your problem is coming from, and so far, it sounds like one or more of your developers are doing merges in a way that prevents mergeinfo from being recorded correctly, for whatever reason. Another question: Do you use path-based authorisation? Do the accounts involved in the merges all have the same set of permissions, or are there differences that might explain your problems? Stefan
Fwd: Repository Directory Tree
I send this email out about once a month or so in what is becoming the vain hope I'll get a response... My subversion repository is in /var/svn. Somehow (and, yes, I'm new; I'm evaluating it), I've wound up with the following directory structure in my subversion repository: /var/svn/ var/svn/proj1 var/svn/proj2 var/svn/proj3. In other words, to do a list of the repositories, I have to do: svn listfile:///var/svn/var/svn to get my projects listed. I've tried to do an svnadmin dump and load with --parent-dir, and that didn't work. This was the command line sequence after I had made a copy of the repository in /var/svn.sav: svnadmin dump /var/svn.sav> old_repos rm -r/var/svn/* svnadmin create /var/svn svnadmin load --parent-dir / /var/svn< old_repos But, even though I had parent-dir as / (to try to eliminate one of the /var/svn's), I still got /var/svn/var/svn/projects. What is the way to do this? TIA, Allen
RE: Repository Directory Tree
Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 From: Allen Williams [mailto:a...@csunv.com] Sent: 06 September 2010 15:28 To: users@subversion.apache.org Subject: Fwd: Repository Directory Tree I send this email out about once a month or so in what is becoming the vain hope I'll get a response... My subversion repository is in /var/svn. Somehow (and, yes, I'm new; I'm evaluating it), I've wound up with the following directory structure in my subversion repository: /var/svn/ var/svn/proj1 var/svn/proj2 var/svn/proj3. In other words, to do a list of the repositories, I have to do: svn listfile:///var/svn/var/svn to get my projects listed. I've tried to do an svnadmin dump and load with --parent-dir, and that didn't work. This was the command line sequence after I had made a copy of the repository in /var/svn.sav: svnadmin dump /var/svn.sav> old_repos rm -r/var/svn/* svnadmin create /var/svn svnadmin load --parent-dir / /var/svn< old_repos But, even though I had parent-dir as / (to try to eliminate one of the /var/svn's), I still got /var/svn/var/svn/projects. What is the way to do this? TIA, Allen Is /var/svn one repository and proj1/2/3 directories inside it? or are proj1/2/3 three separate repositories? How did you create you repository or repositories?
Re: Fwd: Repository Directory Tree
On Mon, Sep 06, 2010 at 10:27:46AM -0400, Allen Williams wrote: > I send this email out about once a month or so in what is becoming > the vain hope I'll get a response... > > My subversion repository is in /var/svn. Somehow (and, yes, I'm new; > I'm evaluating it), I've wound up with the following directory > structure in my subversion repository: > > /var/svn/ > var/svn/proj1 > var/svn/proj2 > var/svn/proj3. > > In other words, to do a list of the repositories, I have to do: Here you say "repositories" > > svn listfile:///var/svn/var/svn > > to get my projects listed. ... and here you say "projects". What do you really mean? svn list does not give you a list of repositories. It gives you a list of folders inside of *a* repostitory. So it looks like there is only one repository here, directly in /var/svn. Inside of that repository, you have a versioned directory also called var/svn. And inside there you have your proj1, proj2, and proj3 folders. > > I've tried to do an svnadmin dump and load with --parent-dir, and that > didn't work. This was the command line sequence after I had made a copy > of the repository in /var/svn.sav: > > svnadmin dump /var/svn.sav> old_repos > rm -r/var/svn/* > svnadmin create /var/svn > svnadmin load --parent-dir / /var/svn< old_repos > > But, even though I had parent-dir as / (to try to eliminate one of the > /var/svn's), I still got /var/svn/var/svn/projects. > > What is the way to do this? You want to remove the leading /var/svn components from all paths in the dump file. See here: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering The part that starts with: "At this point, you have to make a decision. Each of your dump files will create a valid repository, but will preserve the paths exactly as they were in the original repository." is the interesting part you should read especially carefully. Stefan
RE: Fwd: Repository Directory Tree
Stefan Sperling wrote: > On Mon, Sep 06, 2010 at 10:27:46AM -0400, Allen Williams wrote: > > I send this email out about once a month or so in what is > > becoming the vain hope I'll get a response... > > > > My subversion repository is in /var/svn. Somehow (and, yes, I'm > > new; I'm evaluating it), I've wound up with the following > > directory structure in my subversion repository: > > > > /var/svn/ > > var/svn/proj1 > > var/svn/proj2 > > var/svn/proj3. > > [snip] > > > > I've tried to do an svnadmin dump and load with --parent-dir, and > > that didn't work. This was the command line sequence after I had > > made a copy of the repository in /var/svn.sav: > > > > svnadmin dump /var/svn.sav> old_repos > > rm -r/var/svn/* > > svnadmin create /var/svn > > svnadmin load --parent-dir / /var/svn< old_repos > > > > But, even though I had parent-dir as / (to try to eliminate one > > of the /var/svn's), I still got /var/svn/var/svn/projects. > > > > What is the way to do this? > > You want to remove the leading /var/svn components from all paths > in the dump file. See here: > http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html > #svn.reposadmin.maint.filtering > The part that starts with: > "At this point, you have to make a decision. > Each of your dump files will create a valid repository, but will > preserve the paths exactly as they were in the original repository." > is the interesting part you should read especially carefully. > > Stefan I'm wondering if svndumptool could do this automatically. (Maybe 'svndumptool merge -o out.dump -i in.dump -r var/svn/proj1 proj1' ?) But I haven't tried it. See: http://svn.borg.ch/svndumptool/ Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Fwd: Repository Directory Tree
On Mon, Sep 6, 2010 at 10:47 AM, Stefan Sperling wrote: > On Mon, Sep 06, 2010 at 10:27:46AM -0400, Allen Williams wrote: >> I send this email out about once a month or so in what is becoming >> the vain hope I'll get a response... >> >> My subversion repository is in /var/svn. Somehow (and, yes, I'm new; >> I'm evaluating it), I've wound up with the following directory >> structure in my subversion repository: >> >> /var/svn/ >> var/svn/proj1 >> var/svn/proj2 >> var/svn/proj3. Whare are the "db" subdirectories? Do you have 3 different working repositories, one at /var/svn/proj1, another at /var/svn/proj2, another at /var/svn/proj3? Remember, whatever the location of your Subversion repository, it's just a location of a database, one that can be located with a URL used by clients. It's name is actually arbitrary: it's association with a particular, and with branches and tags and a trunk under it, is entirely by convention. Any association with a particular project or set of projects is by your convention, it is not hardcoded anywhere except in your client configurations, that can be updated and altered with the "svn switch" command. >> In other words, to do a list of the repositories, I have to do: > > Here you say "repositories" > >> >> svn listfile:///var/svn/var/svn >> >> to get my projects listed. > > ... and here you say "projects". What do you really mean? > > svn list does not give you a list of repositories. > It gives you a list of folders inside of *a* repostitory. > So it looks like there is only one repository here, directly in /var/svn. > Inside of that repository, you have a versioned directory also called var/svn. > And inside there you have your proj1, proj2, and proj3 folders. That's how I'd interpret it. The switch of syntax from "/var/svn/" to the syntax of "var/svn/proj1" is very confusing. Does our friendly original poster mean that inside of his repo at file:///var/svn/, he has subdirectories for his pojects called var/svn/proj1, var/svn/proj2, var/svn/proj3, or something else equally outre? >> I've tried to do an svnadmin dump and load with --parent-dir, and that >> didn't work. This was the command line sequence after I had made a copy >> of the repository in /var/svn.sav: >> >> svnadmin dump /var/svn.sav> old_repos >> rm -r/var/svn/* >> svnadmin create /var/svn >> svnadmin load --parent-dir / /var/svn< old_repos And this is just. oddness. That "rm -r/svn/* obviously would not work, due to the missing space between the "-r" and its targets. >> But, even though I had parent-dir as / (to try to eliminate one of the >> /var/svn's), I still got /var/svn/var/svn/projects. Ohh, deaar. OK, you've devinitely got subdirectories in your repository at var/svn/project1, var/svn/projects, etc. >> >> What is the way to do this? > > You want to remove the leading /var/svn components from all paths > in the dump file. See here: > http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering > The part that starts with: > "At this point, you have to make a decision. > Each of your dump files will create a valid repository, but will > preserve the paths exactly as they were in the original repository." > is the interesting part you should read especially carefully. Yeah. I think you've got it. Unfortunately, this can create serious historical preservation issues if code has started out in "higher level" directories and been migrated around. Allen? How bad would it be to simply move aside /var/svn/, export its contents, and create a clean new repository with the structure you want? I've often found it far simpler to set a cut-off date, notify users of the rebuild, and switch to a clean new layout with a clean new repo. It creates issues for people with un-integrated local changes, but it can be a lot simpler than getting cute with dumping and re-arranging components. A simple "README.txt" at the top of the repository, and setting it to read-only mode in an "archive" location, can be your savior here.
Re: SSL handshake failed: SSL error: A TLS warning alert has been received.
On Mon, Sep 6, 2010 at 5:40 AM, Bert Huijben wrote: > > >> -Original Message- >> From: Gero [mailto:g...@ieee.org] >> Sent: maandag 6 september 2010 11:37 >> To: users@subversion.apache.org >> Subject: Re: SSL handshake failed: SSL error: A TLS warning alert has been >> received. >> >> On Wed, 2010-08-18 at 02:06 -0400, Nico Kadel-Garcia wrote: >> On Wed, Aug 11, 2010 at 10:24 AM, Gero wrote: >> > > Hi, >> > > >> > > After moving to a new system (Kubuntu Hardy -> Lucid) I can no >> longer access >> > > an SVN repository: >> > > >> > > $ svn update >> > > svn: OPTIONS of 'https://example.com/path/to/svn/trunk': SSL >> handshake >> > > failed: SSL error: A TLS warning alert has been received. >> > > (https://example.com) >> > >> > But 'svn info 'https://example.com/path/to/svn/trunk works? What about >> > doing a clean checkout to a new location? >> >> 'svn info' with no arguments works and shows info about the repository >> in question. 'svn info ', however, does not work, with the same >> error message as above. A clean checkout doesn't work either. >> >> There is an Ubuntu bug report about Subversion not playing with the >> latest libneon nor libneon-gnutls. Apparently, libneon now reports more >> SSL problems that Subversion should ignore, but doesn't. > > Subversion uses neon and neon uses your SSL library. Subversion doesn't use > the ssl library directly. > > So this should be fixed either in Neon or (to restore compatibility with the > older version) in the SSL library. > > Bert Really? Why do you think this? For RHEL 5, the RPMforge packages actually have to include compatibility versions of python, neon, and swig. Component drift for the 4 major and several variant methods of accessing a Subversion repository is a demonstrable issue: between local file access, svnserve, HTTP, and the minor variants of HTTPS and ssh+svn, you have a potential for a lot of subtle version skew in components themselves and especially in the interfaces to those components. It's already awkward with enterprise operating systems, which are very reluctant to upgrade system components. (See the RHEL 5 comment, and I went through this with SCO OpenServer 5 myself.) It seems unsurprising that Ubuntu, that tends to be leading edge, is encountering version skew issues from the other side.
