Re: Fine and secure dining, was Re: svnadmin create and not being method agnostic

[Johan Corveleyn]

On Thu, Jan 6, 2011 at 1:29 AM, Nico Kadel-Garcia  wrote:
> On Wed, Jan 5, 2011 at 2:19 PM, Les Mikesell  wrote:
>
>> Of course you _can_ secure it.  My point is that permitting ssh and
>> restricting access to ssh by itself is very likely to make your system less
>> secure (if you count on firewall protections) instead of more so. And
>> nothing that can be done in the default svn installation can fix it.
>
> It's an issue. The layers and layers of external-to-subversion hackery
> to secure any of the multiple forms of access is fairly burdensome.
> Coupled with the lack of configuration tools for the SSH key
> management, and it's a compounded problem. Alternative port use, and
> restricting a separate SSHD for external access with only a single
> user allowed and access restricted to SSH keys, it's a lot better, but
> those are extra and fairly painful steps.
>
> Mind you, compared to storing the HTTP/HTTPS passwords in clear text
> in fashions that are unstoppable by the server and is enabled by
> default in all UNIX and Linux clients, it's a 2 inch thick vault door,

Oh, come on. From the server side you can never control what I do as a
user with my password. If I find it convenient to use the same
password on facebook, there is not much you as a sysadmin can do about
it.

So if I'm on *nix, without gnome-keyring and KDE-wallet, and I decide
to ignore the warning "this will store the password in clear-text in
your homedir, are you sure?", which my sysadmin specifically
instructed me *not to do*, that's basically the same thing. Well, it's
actually vastly less severe than re-using that password for other
(non-company) services, because the password is still only in a file
that's in my homedir with permissions that make it readable only by
me.

Cheers,
-- 
Johan

Re: 答复: svn: REPORT request failed on '/svn/!svn /bc/20890'

[Johan Corveleyn]

[ please don't top-post on this list, i.e. put your reply inline or
below the thing you're replying to, thanks. See below for more ... ]

> Johan Corveleyn wrote:
> On Wed, Jan 5, 2011 at 3:18 PM, zhangfan  wrote:
>> Hi All
>>
>>  I am using svn1.6.3. I put all source code and documents of our
>> team into one repo. It works great for two years until last month. Now when
>> I run 'svn log http://192.168.0.3:907/svn' (where 192.168.0.3 is our
>> server's address), svn returns 'svn: REPORT request failed on
>> '/svn/!svn/bc/20890' after returned some log information.
>>
>>  Is there anyone know how to handle this? Our server is: Windows2003
>> + Apache2.2
>>
>>  Thanks for reading this letter,and thanks for any help!
>
> Is the url of the repository still correct? Maybe it was moved
> somehow, or there is some kind of connection problem?
>
> Can you try to browse to http://192.168.0.3:907/svn with a browser?
>

On Thu, Jan 6, 2011 at 2:04 AM, zhangfan  wrote:
> Hi Johan,
>The url is correct,and I can connect the repository with IE and 
> TortoiseSVN. We are using JIRA's svn plugin which using svn log to associate 
> issues with code commit. This problem stops the plugin's work.
>

It's most likely a connectivity problem. When you connect from IE and
TortoiseSVN, is that from the same machine as where the JIRA server is
running? Can you run the same "svn log" command, from the same machine
as JIRA, with a svn command line client?

Sometimes this kind of error is caused by proxy servers, which don't
always fully understand/support the svn protocol (WebDAV methods).

Cheers,
-- 
Johan

Re: 207 Multi-Status error checking out WebKit repository on Windows

[Nick]

On Wed, 2011-01-05 at 19:52 -0500, Nick wrote:
> On Tue, 2011-01-04 at 17:29 -0800, Blair Zajac wrote:
> > On 12/25/10 5:42 PM, Kenneth Russell wrote:
> > > Hello,
> > >
> > > The WebKit project uses Subversion for version control and we are
> > > facing a problem with fresh checkouts of the repository on Windows
> > > with Subversion 1.6.6 (as well as earlier versions -- I've also tried
> > > 1.6.1). The reported error is with a specific file:
> > >
> > > svn: PROPFIND of
> > > '/repository/webkit/!svn/bc/19963/trunk/LayoutTests/fast/xpath/4XPath/Core/test.js':
> > > 207 Multi-Status (http://svn.webkit.org)
> > >
> > > The WebKit project maintainers aren't sure what changed with this
> > > particular file to cause this error to start occurring. I was only
> > > able to get past it by copying the .svn directory for this
> > > subdirectory from another Windows machine (where the checkout predated
> > > the problematic changes to this file) and then continuing the
> > > checkout.
> > >
> > > Is this a known issue? Can you reproduce it by checking out the
> > > repository (see http://webkit.org/building/checkout.html) with the
> > > current (non-Cygwin) Subversion binaries?
> > 
> > If you try with an https URL, do you see the same issue?  That will avoid 
> > any 
> > networking issues you may be running into.
> > 
> > https://svn.webkit.org/repository/webkit/trunk
> 
> FYI:  I successfully checked out webkit on linux using SVN 1.6.13.  I'll
> try on Windows the next time I start it in the VM.

I successfully checked out webkit on Windows today using SVN 1.6.15 and
verified the file LayoutTests/fast/xpath/4XPath/Core/test.js exists and
with some content.

Nick

Re: svn: REPORT request failed on '/svn/!svn/bc/20890'

[Ryan Schmidt]

On Jan 5, 2011, at 08:18, zhangfan wrote:

>  I am using svn1.6.3. I put all source code and documents of our team 
> into one repo. It works great for two years until last month. Now when I run 
> ‘svn log http://192.168.0.3:907/svn’ (where 192.168.0.3 is our server’s 
> address), svn returns ‘svn: REPORT request failed on '/svn/!svn/bc/20890' 
> after returned some log information.

You say it does return some log information, but not all of it? Sounds like 
maybe a corrupted revision in the repository. You could try running "svnadmin 
verify". There are also some other tools you could run depending on whether 
it's a BDB or FSFS repository.

request for new feature

[georgi . nikolov]

Dear Sirs

Is there a way to make SVN in Windows OS automatically add new-created
files which are in the monitor list. This will be very helpful and
useful because there are many times in which not all the files made by
someone are added because some of them are missed somehow.

We will be very grateful if you add this feature, because it will help
us very much in our daily work

Thank you in advance
Regrads
Georgi Nikolov
Software Developer

Adding arbitrary file to repo

[natarajmb]

Hi All,
  This might be discussed and beaten to death before; but I am new to 
SVN; I am writing a scripts to do a tagging and branching
using python, my question is I want to add a README file on the newly 
created tag where README is a generated file and doesn't exist in WC or
the trunk. I am using svn copy to create new tag. Look forward to 
replay's

Regards,
Nataraj

Re: 答复: svn: REPORT request f ailed on '/svn/!svn/bc/20890'

[JamieEchlin]

>>  I am using svn1.6.3. I put all source code and documents of our
>> team into one repo. It works great for two years until last month. Now
>> when
>> I run 'svn log http://192.168.0.3:907/svn' (where 192.168.0.3 is our
>> server's address), svn returns 'svn: REPORT request failed on
>> '/svn/!svn/bc/20890' after returned some log information.

Things generally don't *just stop* working after two years, fortunately.
Something must have changed. 

> We are using JIRA's svn plugin which using svn log 

This is not entirely true. Have you upgraded jira? The jira-svn integration
uses svnkit (not native svn), if you've upgraded jira then the version of
svnkit would have been bumped, maybe it's incompatible now.

As well as what the others have suggested I'd try putting svnkit (same
version which jira uses) on the box, and run your log and other comments
with jsvn.bat. This was helpful to me in debugging issues with svn+ssh
connections between jira and svn.

(Although this doesn't explain why svn log is not working but it works from
tortoise).

jamie
-- 
View this message in context: 
http://old.nabble.com/svn%3A-REPORT-request-failed-on-%27-svn-%21svn-bc-20890%27-tp30596624p30605691.html
Sent from the Subversion Users mailing list archive at Nabble.com.

Re: Adding arbitrary file to repo

[Andy Levy]

On Wed, Jan 5, 2011 at 07:01,   wrote:
> Hi All,
>  This might be discussed and beaten to death before; but I am new to SVN; I
> am writing a scripts to do a tagging and branching
> using python, my question is I want to add a README file on the newly
> created tag where README is a generated file and doesn't exist in WC or
> the trunk. I am using svn copy to create new tag. Look forward to replay's

Since you're already scripting the tagging & branching, why can't you
have the script generate & add your README file?

subversion client hooks - any advice?

[JamieEchlin]

Afternoon,

Following a spate of high-profile subversion problems at my $client, we've
decided to implement both client and server "sanity" hooks, which we're
hoping will prevent most of the problems from happening again.

I'm working on the client part at the moment, which will take the form of
tortoisesvn hooks. Before I spend too much time on it I wanted to get some
opinions from the experts, in case I'm going off in the wrong direction.

The client side will just warn users about potential issues and prod them in
the right direction, given that it would be trivial to bypass the client
hooks anyway, eg by using cmd line.

Most of the user angst has been generated by doing cherry-picking... eg,
dealing with tree conflicts, the "Attempt to add tree conflict that already
exists"  http://svn.haxx.se/dev/archive-2010-11/0295.shtml bug , having to
resolve conflicts multiple times when merging broken ranges, 
http://svn.haxx.se/users/archive-2010-11/0442.shtml losing data  through
merging into a conflicted file etc.

The client tool will simply 1) warn that there are revs with lower numbers
than the one they have actually merged which are eligible for merge. I think
often when people (here) cherry pick they don't realise that's what they're
doing, they just merge the revs they think they need.

It will also, using a differencing algo, try to match unversioned/added
files with missing/removed files, and 2) warn that a rename has been done
outside of subversion. At this stage it just recommends the user to fix them
using tsvn's useful but rather well-hidden feature to handle this. (Aside:
could this be more prominent in tsvn? TortoiseHg has this feature built-in).
We see this happen mostly through use of IDE plugins which are not aware
that a VCS is in use.

Next, it looks for files that are unversioned or added, when they should
have been added with history. This happens when a user does a merge where
new files are added, reverts all (which resurrects deleted files, undoes
mods, but contrary to all intuition leaves added files as unversioned
files), then does the merge again. 

This check 3) looks at the revisions that have been merged, looks for added
files in each ones, and verifies that files with the same names don't exist
as unversioned files in the WC. Aside: Could tsvn treat "skipped files" as
at least a serious problem as conflicts? These are easily missed. Even if
they're noticed by the user, "skipped files" sounds benign, like they'll
just be merged across next time someone does a merge, except they totally
won't, and will lead to tree conflicts in future merges.

Finally it 4) looks for subtree merge info and warns users to do a merge
from the branch root. Whilst this is supposed to not be a problem, in
practice we've seen a lot of issues caused by this.

I was working on 5) trying to ensure branches and tags are made from clean,
non-mixed working copies, but as these tend to be done WC->URL the tsvn hook
can't catch this, so it will have to be done server-side.

Anyway, grateful for any advice on any of these checks.

jamie




-- 
View this message in context: 
http://old.nabble.com/subversion-client-hooks---any-advice--tp30605816p30605816.html
Sent from the Subversion Users mailing list archive at Nabble.com.

Re: Commit fails with path not found

[Pazmiño Mazón , Iván Andrés]

This project went through some big refactoring. It was not a maven
project at first and had very different directories structure. The
modules did not exist before so all the -ejb -ear and -web directories
are new and the source and other files inside were originally in
directories on the root directory.

I've looked into some of the problem directories and no one is marked
with (!)

-Original Message-
From: David Weintraub 
To: iapazm...@sri.gob.ec
Cc: users@subversion.apache.org
Subject: Re: Commit fails with path not found
Date: Wed, 5 Jan 2011 16:56:35 -0500

Interesting. These look like directory names. The ones that start with
"?" are not under Subversion control. Are these the ones you moved? The
directoy is "src/main/java/...", so I assume these should be under
version control. Did you move your directories around?


The strange thing is the "~" mark. This is for versioned items that are
obstructed. For example, if I delete a directory, and put a file in its
place. However, these are for "target" directories which I assume should
not be under version control. Did you put the "target" directory under
revision control? The "obstructed version object flag" (~) could happen
if you delete the revisioned target directories and then put duplicate
non-revisioned "target" directories in their place.


Are there any directories or files showing up with the "missing
flag" (!)?

2011/1/5 Pazmiño Mazón, Iván Andrés 
Thanks a lot David!

This is the output to my status command:

iapm270...@uioiapm270409:~/workspace/intranet/recursos-revision$
svn
status
 M  .
~   recursos-revision-ejb/target
?
recursos-revision-ejb/src/main/java/ec/gob/sri/recursos/revision/comun
?

recursos-revision-ejb/src/main/java/ec/gob/sri/recursos/revision/ejb/entidades
?

recursos-revision-ejb/src/main/java/ec/gob/sri/recursos/revision/ejb/exception
?

recursos-revision-ejb/src/main/java/ec/gob/sri/recursos/revision/ejb/dao/impl
?

recursos-revision-ejb/src/main/java/ec/gob/sri/recursos/revision/servicio/impl
~   recursos-revision-ear/target
~   recursos-revision-web/target
?   recursos-revision-web/src/main/config
?   recursos-revision-web/src/main/webapp
?   recursos-revision-web/src/main/java/ec
A   .settings
A   .settings/org.eclipse.jdt.core.prefs
A   .settings/org.maven.ide.eclipse.prefs

The command was run on the projects base directory.

-Original Message-
From: David Weintraub 
To: iapazm...@sri.gob.ec
Cc: users@subversion.apache.org
Subject: Re: Commit fails with path not found


Date: Tue, 4 Jan 2011 12:08:27 -0500

2011/1/4 Pazmiño Mazón, Iván Andrés :
> I just moved the directories within the IDE, it's eclipse, and
worked
on
> them for quite long before being ready to commit. I'm using
subversive
> plugin.

If you don't have the command line Subversion client installed,
install
it on your system, and try the following:

Go to the directory where your files are checked out and run:

C> svn status

This will print out the status of the various files in your
working
directory. If the first column is an exclamation point (!), it
means
that the file exists in Subversion, but does not exist in your
working
directory. If the first column of the report is a question mark
(?), it
means that the item is not under version control.

I have a feeling that when you moved files around with Eclipse,
it
didn't inform Subversion what you were doing, and you'll see the
files
in the directory where they were moved starting with a "?" and
in the
directory where they were moved from, you'll see a "!".

I just played around with my Subversion install, and see the
following:

  H:\svn> move groups.pl File
  H:\svn> svn status
  ?   File\groups.pl
  !   groups.pl
  M   updateRms.cqpl

I first moved the file "groups.pl" to the File directory, and
ran "svn
status".


The first line in the status report is telling me that the file
"groups.pl" is under the "File" directory, but is not under
version
control. The second line is telling me that the file "groups.pl"
should
be in the current directory, but isn't found there. Subversion
may not
let me commit my changes. (It might, but I'm not going to see
what
happens).


What I should have done was:


   H:\svn> svn move groups.pl File
   A File\groups.pl
   D   

RE: Hooks That Use Perl Test::Builder Having Problems with STDERR

[eric.berg]

From: David Weintraub [mailto:qazw...@gmail.com]
Sent: Wednesday, January 05, 2011 6:04 PM
To: Berg, Eric: IT (NYK)
Cc: users@subversion.apache.org
Subject: Re: Hooks That Use Perl Test::Builder Having Problems with STDERR
On Wed, Jan 5, 2011 at 5:03 PM, 
mailto:eric.b...@barclayscapital.com>> wrote:
Dave, if you look into how the hooks work, basically, they are passed a repo 
path and a transaction id that, using svnlook, gives you access to copies of 
the working files, so it doesn't matter where the hooks run, nor is there any 
requirement for server/client communication.

I've written quite a few hooks. I have a hook script that implements watches.  
8<8<

However, I take it that in order to run the tests, you need these files written 
to a directory, and you may need dependent files there too. That starts getting 
a bit more complex than what "svnlook" was built for. In theory, you could 
checkout a working directory on a hook script, then use "svnlook cat" to update 
the files that are being committed, and run your tests. It's complex, and can 
take a long time.

Nonissue.  We've been doing this with CVS hooks for almost 10 years.  It's 
"just a port" ;(  and I'm not even going to bring up the issues that I will 
undoubtedly run into when I get to work on the DEPLOYMENT piece.

Even after all of that, Subversion captures STDOUT and STDERR and they don't 
get printed out to a console. If you want to see them, you'll have to capture 
them and then either write them to a logfile, or email them.

This is a larger issue for us, specifically WRT the Test::Builder tests that 
we've implemented.  The way this was done was to make any Perl class which 
required tests to be a subclass of our UnitTest class, which runs any 
subroutines with names that begin with "test_".  Each of these has some number 
of Test::* tests.  With CVS, we see the progress of the tests as they complete 
-- whether they succeed or fail.  With SVN, we'd only see failures.

This is where I'm having some issues with the STDERR output.  I haven't dug 
down deeply enough understand the impace of the "stacked redirection" of SVN's 
doing a STDERR/OUT capture, then the Test::* mods doing their own redirect.  
What i have seen is that the only place that the stderr appears once these 
tests are run is the web server logs.  A simple test which simply dies in my 
precommit hook shows up fine to the client's stderr.

Though I do love immediate checkins, I'm not sure where you're going when you 
suggest that our validations might be better handled some way other than by 
hooks.  That appears to be the whole reason to have such hooks:  to validate 
files before allowing a checkin.

How long does it take your pre-commit hook to run? Even a few seconds can seem 
like an eternity to a developer who is making a few minor changes. If every 
time a developer does a commit, they have to wait, they simply will stop making 
commits when they should. And, they'll learn to hate Subversion because it is 
slow and buggy.

Don't forget that this has been the standard for our checkins here since time 
immemorial.   Developers are pretty much used to it, if not simply resigned.  I 
appreciate the stringent code validation regime that enforces a number of 
checks in addition to the unit tests.

It can take from 30 seconds up to several minutes.  For database code, often, 
actual temporary deploys are followed by tests to validate what's been deployed 
are  valid before allowing the checkins to continue.  Again, this seems like a 
good place NOT to mention our CVS tag-based deploys, which can take a VERY long 
time to deploy to our ~40 db's, etc.
Remember that Subversion is a version control system which means you can undo 
stuff that should never have been committed in the first place. Doing tests 
during the build cycle has lots of advantages:

I'm in the middle here, being the developer responsible for this porting 
project.  I mentioned the deployment stuff too, which I fear, and which I fear 
is far less appropriate to be implemented via SVN hooks.  Your input is 
appreciated.  We could go back-and-forth endlessly, but ultimately, it's not my 
decision.  There's a lot of inertia influencing this as well, not to mention 
that this is just one of my projects, and that our organization has 
discontinued support for CVS, so we're kind of working without a net at the 
moment.

Not sure how this is going to go, but the input is, again, appreciated.

* You have room to checkout your entire project and have access to all the 
files. That can make running your tests much simpler to do.
* You can use Hudson as your framework (or another build server). That means 
the reporting, running, and checking the results are all done for you. There's 
no reinventing the wheel.
 * Your commits are now much faster.
* Your tests have their own environment and won't interfere with Subversion
* You have a complete log of your tests, and you can re

Re: Best way to maintain patches to a 3rd party library?

[NN Ott]

>
> > >
> > > I have a source library that I need to periodically import (and then
> patch)
> > > for use by my code base.
> > >
> > > The SVN Book seems to reccomend a "vendor branch" scheme where you keep
> a
> > > patched branch of the "vendor drops". This would work, except that I
> loose
> > > any history of the library development.  (The vendor also uses SVN and
> gives
> > > read-only access to their repo.)
> >
>
>
> The above steps can also semi-automated using svn_load_dirs:
>
> https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs
>
>
>
Stefan,

That is what the SVN books recommended, but then I can not access the
original commit history of the 3rd-party library.

(The other option is to use svn:external and patch manually.)

This is exactly the crux of my question:

Can I make a local (patched) branch of an svn:external?  That way I could
pull updates as needed, but still retain access to the full commit history.

Thank you

Re: Hooks That Use Perl Test::Builder Having Problems with STDERR

[Daniel Shahaf]

eric.b...@barclayscapital.com wrote on Wed, Jan 05, 2011 at 17:03:11 -0500:
> Dave, if you look into how the hooks work, basically, they are passed a repo 
> path and a transaction id that, using svnlook, gives you access to copies of 
> the working files, so it doesn't matter where the hooks run, nor is there any 
> requirement for server/client communication.
> 
> Though I do love immediate checkins, I'm not sure where you're going when you 
> suggest that our validations might be better handled some way other than by 
> hooks.  That appears to be the whole reason to have such hooks:  to validate 
> files before allowing a checkin.
> 
> How would hudson help to validate files in the context of a checkin 
> transaction?
> 

Hudson validates after the commit.  But you could commit to one branch,
have hudson validate, and if validation passes merge to trunk.

(David, if you already said that in your response, sorry for the
duplication)

> Eric
> 
> 
> 
> From: David Weintraub [mailto:qazw...@gmail.com]
> Sent: Wednesday, January 05, 2011 4:37 PM
> To: Berg, Eric: IT (NYK)
> Cc: users@subversion.apache.org
> Subject: Re: Hooks That Use Perl Test::Builder Having Problems with STDERR
> 
> On Wed, Jan 5, 2011 at 11:30 AM, 
> mailto:eric.b...@barclayscapital.com>> wrote:
> I'm working on porting a fairly extensive set of CVS hooks to SVN.
> 
> Okay. Stop right there. When ever someone mentions "a fairly extensive set" 
> of hooks, I start to think maybe most of what they want shouldn't necessarily 
> be hooks. When hooks are running, the client is sitting there waiting for the 
> results. I've been at one place where it wasn't unusual for a commit to take 
> almost a minute for reformatting, testing, etc. Those were a group of very 
> frustrated developers.
> 
> Besides, how can you even run your tests? The hooks execute on the Subversion 
> server, yet the working directory is on the client There's no communication 
> between the server and client until the hooks are complete.
> 
> > The issue that I'm having now is that my pre-commit hook, which runs a Perl 
> > script
> > that performs tests based on Test::Builder and Test::More, never show their 
> > stderr
> > on the console.  I see it in the svn web server logs, but not on the 
> > console.
> 
> The problem is that Subversion swallow STDOUT and STDERR from the hooks, and 
> Subversion won't display STDERR unless the hook script returns a non-zero 
> exit value, and only then, it displays it on the developer's console. That 
> may be your problem.
> 
> Do you have  continuous build server like Hudson (http://hudson-ci.org)? Even 
> if you don't need to compile code, you can use something like Hudson for 
> running your tests. Hudson can checkout the project from the Subversion 
> repository, run tests, and then report back the results.
> 
> Moving your testing to Hudson will simplify your life and help keep a running 
> record of your test results. Hudson won't interfere with Test::Builder and 
> Test::More, and you'll be able to keep the test results of all of your check 
> ins in one easy to find place.
> 
> --
> David Weintraub
> qazw...@gmail.com
> 
> ___
> 
> This e-mail may contain information that is confidential, privileged or 
> otherwise protected from disclosure. If you are not an intended recipient of 
> this e-mail, do not duplicate or redistribute it by any means. Please delete 
> it and any attachments and notify the sender that you have received it in 
> error. Unless specifically indicated, this e-mail is not an offer to buy or 
> sell or a solicitation to buy or sell any securities, investment products or 
> other financial product or service, an official confirmation of any 
> transaction, or an official statement of Barclays. Any views or opinions 
> presented are solely those of the author and do not necessarily represent 
> those of Barclays. This e-mail is subject to terms available at the following 
> link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent 
> to the foregoing.  Barclays Capital is the investment banking division of 
> Barclays Bank PLC, a company registered in England (number 1026167) with its 
> registered office at 1 Churchill Place, London, E14 5HP.  This email may 
> relate to or be sent from other members of the Barclays Group.
> ___

Re: 207 Multi-Status error checking out WebKit repository on Windows

[Kenneth Russell]

On Tue, Jan 4, 2011 at 5:29 PM, Blair Zajac  wrote:
> On 12/25/10 5:42 PM, Kenneth Russell wrote:
>>
>> Hello,
>>
>> The WebKit project uses Subversion for version control and we are
>> facing a problem with fresh checkouts of the repository on Windows
>> with Subversion 1.6.6 (as well as earlier versions -- I've also tried
>> 1.6.1). The reported error is with a specific file:
>>
>> svn: PROPFIND of
>>
>> '/repository/webkit/!svn/bc/19963/trunk/LayoutTests/fast/xpath/4XPath/Core/test.js':
>> 207 Multi-Status (http://svn.webkit.org)
>>
>> The WebKit project maintainers aren't sure what changed with this
>> particular file to cause this error to start occurring. I was only
>> able to get past it by copying the .svn directory for this
>> subdirectory from another Windows machine (where the checkout predated
>> the problematic changes to this file) and then continuing the
>> checkout.
>>
>> Is this a known issue? Can you reproduce it by checking out the
>> repository (see http://webkit.org/building/checkout.html) with the
>> current (non-Cygwin) Subversion binaries?
>
> If you try with an https URL, do you see the same issue?  That will avoid
> any networking issues you may be running into.
>
> https://svn.webkit.org/repository/webkit/trunk

Thanks for the suggestion. I was able to successfully check out the
WebKit repository on Windows with Subversion 1.6.6 from the https URL.
I haven't yet re-tried checking out from the http URL to confirm the
207 Multi-Status error was 100% reproducible on this machine.

-Ken

Re: svn: REPORT request failed on '/svn/!svn/bc/20890'

[Daniel Shahaf]

If it's a corrupted revision, the server's error log should say something.

Ryan Schmidt wrote on Wed, Jan 05, 2011 at 20:48:34 -0600:
> On Jan 5, 2011, at 08:18, zhangfan wrote:
> 
> >  I am using svn1.6.3. I put all source code and documents of our 
> > team into one repo. It works great for two years until last month. Now when 
> > I run ‘svn log http://192.168.0.3:907/svn’ (where 192.168.0.3 is our 
> > server’s address), svn returns ‘svn: REPORT request failed on 
> > '/svn/!svn/bc/20890' after returned some log information.
> 
> You say it does return some log information, but not all of it? Sounds like 
> maybe a corrupted revision in the repository. You could try running "svnadmin 
> verify". There are also some other tools you could run depending on whether 
> it's a BDB or FSFS repository.
> 
> 

Re: 207 Multi-Status error checking out WebKit repository on Windows

[Blair Zajac]

On 1/6/11 10:30 AM, Kenneth Russell wrote:

On Tue, Jan 4, 2011 at 5:29 PM, Blair Zajac  wrote:

On 12/25/10 5:42 PM, Kenneth Russell wrote:


Hello,

The WebKit project uses Subversion for version control and we are
facing a problem with fresh checkouts of the repository on Windows
with Subversion 1.6.6 (as well as earlier versions -- I've also tried
1.6.1). The reported error is with a specific file:

svn: PROPFIND of

'/repository/webkit/!svn/bc/19963/trunk/LayoutTests/fast/xpath/4XPath/Core/test.js':
207 Multi-Status (http://svn.webkit.org)

The WebKit project maintainers aren't sure what changed with this
particular file to cause this error to start occurring. I was only
able to get past it by copying the .svn directory for this
subdirectory from another Windows machine (where the checkout predated
the problematic changes to this file) and then continuing the
checkout.

Is this a known issue? Can you reproduce it by checking out the
repository (see http://webkit.org/building/checkout.html) with the
current (non-Cygwin) Subversion binaries?


If you try with an https URL, do you see the same issue?  That will avoid
any networking issues you may be running into.

https://svn.webkit.org/repository/webkit/trunk


Thanks for the suggestion. I was able to successfully check out the
WebKit repository on Windows with Subversion 1.6.6 from the https URL.
I haven't yet re-tried checking out from the http URL to confirm the
207 Multi-Status error was 100% reproducible on this machine.


Ken,

That's great.  Sounds like a proxy may be getting in the way.

BTW, some Googler's do work on svn, such as the Google Code people, if you ever 
need help :)


Regards,
Blair

Re: Commit fails with path not found

[David Weintraub]

The directories that might be causing all the trouble are the "target"
directories marked with the "~" mark. Subversion has these directories as
versioned items, but they were replaced.

I know Maven deletes those directories on a "clean", so I suspect that you
did a checkout, created these directories, and did a rebuild. That would
have created new "target" directories that prevent Subversion from putting
its versioned "target" directories.

The directories that start with a "?" should be causing Subversion commit
issues.

Try this from the command line:

1). Delete the 3 "target" directories. Under Maven, there shouldn't be
anything in there that you need. However, you might want to verify that
first anyway. You should be able to remove them with a "mvn clean".

2). Do a "svn update". This should recreate the target directories, but
these will now be Subversion's version of these directories.

3). Run "svn status" one more time. Make sure that you don't have any
listings with "!", "~", or "C" in the first column. The "?" are fine and
shouldn't block a commit (although you probably want to add them to the
repository, but let's take care of one problem at a time).

4). Now try the commit once more. You can do that from the command line with
a "svn commit". The build might not work right this second, but we can fix
that in a couple of minutes. Let's make sure you can commit your stuff.

5). If you can do a commit, your next step is to remove the "target"
directories using the "svn delete" command. These should not be stored in
Subversion.

6). You might want to add in the directories with the "?" before we do
another commit. you can use the "svn add" command. The "svn add" will
recurse automatically through the directories and add in any sub directories
and files.

7). Now commit once more. Your workspace should be clean. There are no more
"target" directories in your repository. Although, you might still have them
on your disk. Again, "mvn clean" should get rid of them.

8). Now refresh your Eclipse workspace and everything should be fine.


-- 
David Weintraub
qazw...@gmail.com

Re: Best way to maintain patches to a 3rd party library?

[Stefan Sperling]

On Thu, Jan 06, 2011 at 11:43:31AM -0500, NN Ott wrote:
> >
> > > >
> > > > I have a source library that I need to periodically import (and then
> > patch)
> > > > for use by my code base.
> > > >
> > > > The SVN Book seems to reccomend a "vendor branch" scheme where you keep
> > a
> > > > patched branch of the "vendor drops". This would work, except that I
> > loose
> > > > any history of the library development.  (The vendor also uses SVN and
> > gives
> > > > read-only access to their repo.)
> > >
> >
> >
> > The above steps can also semi-automated using svn_load_dirs:
> >
> > https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs
> >
> >
> >
> Stefan,
> 
> That is what the SVN books recommended, but then I can not access the
> original commit history of the 3rd-party library.

If you can access their svn repository, you can also access their
commit history, no?

> (The other option is to use svn:external and patch manually.)
> 
> This is exactly the crux of my question:
> 
> Can I make a local (patched) branch of an svn:external?  That way I could
> pull updates as needed, but still retain access to the full commit history.

You'd need to manually (or some automated fashion) apply each commit
made to their repository to your own repository.
This is very tedious if they make a lot of commits.
And revision numbers between repositories wouldn't match up.

I don't understand what the real problem you want to solve is.
Maybe you want to browse their history without internet access?
If you want to browse their history without internet access, I would
recommend keeping an svnsync copy of their repository on your hard drive.

Stefan

Re: Best way to maintain patches to a 3rd party library?

[Les Mikesell]

On 1/6/2011 5:41 PM, Stefan Sperling wrote:



Can I make a local (patched) branch of an svn:external?  That way I could
pull updates as needed, but still retain access to the full commit history.


You'd need to manually (or some automated fashion) apply each commit
made to their repository to your own repository.
This is very tedious if they make a lot of commits.
And revision numbers between repositories wouldn't match up.

I don't understand what the real problem you want to solve is.
Maybe you want to browse their history without internet access?
If you want to browse their history without internet access, I would
recommend keeping an svnsync copy of their repository on your hard drive.


I think the idea is that he'd like to see the development history of 
both the vendor and local changes as a continuous set of changes as you 
would if they were in the same repository with log and diff working 
across any points in time or branch versions.  It seems like a 
reasonable thing to want, but I don't think it is possible with subversion.


--
 Les Mikesell
   lesmikes...@gmail.com

Re: Best way to maintain patches to a 3rd party library?

[NN Ott]

>
>
>
>>  Can I make a local (patched) branch of an svn:external?  That way I could
>>> pull updates as needed, but still retain access to the full commit
>>> history.
>>>
>>
>> You'd need to manually (or some automated fashion) apply each commit
>> made to their repository to your own repository.
>> This is very tedious if they make a lot of commits.
>> And revision numbers between repositories wouldn't match up.
>>
>> I don't understand what the real problem you want to solve is.
>> Maybe you want to browse their history without internet access?
>> If you want to browse their history without internet access, I would
>> recommend keeping an svnsync copy of their repository on your hard drive.
>>
>
> I think the idea is that he'd like to see the development history of both
> the vendor and local changes as a continuous set of changes as you would if
> they were in the same repository with log and diff working across any points
> in time or branch versions.  It seems like a reasonable thing to want, but I
> don't think it is possible with subversion.
>
>
>
That's exactly right.

Should I post this to the dev list?

Force Subversion to grab information from Mac OS X keychain

[Kevin Lindeman]

Hi,

I am running Subversion on Mac OS X. I noticed that once I login correctly
for an https subversion URL, it will create a file in ~/.subversion/auth/
that seems to point Subversion to where it stores the authentication - in
this case, it has the realmstring, username, "passtype", which is set to
keychain. That makes it know that it should be using the keychain from then
on to remember the password.

I am trying to automate some subversion processes, so I launch subversion,
give it arguments arguments, and even set some environment variables (such
as SVN_SSH, which allows me to tell SVN how to launch ssh, ie: with a
special username).

Unfortunately, my automation has no way to intercept the password prompt for
an http url. I can intercept the SSH login prompt for svn+ssh by setting the
SSH_ASKPASS environment variable. I already have been automating the process
of adding the password to the keychain (using the realmstring format, so svn
can find it once it knows to find it in the keychain).

But it looks like I am missing that critical file in ~/.subversion/auth/
that has the "passtype" set to keychain. Is there a way I can force SVN to
always use that as the passtype, either with an argument or an environment
variable?

If not, is it possible to force the creation of that file with some magic
SVN command? I thought of just running an svn info with my login info as
arguments since I noticed that file is created on a successful login, but
unfortunately many servers don't request authorization for info requests so
that doesn't work.

I don't think I will be able to solve this by using a setting in the
subversion config file.

Thanks,
- Kevin

[no subject]

[Altaf-Hussain Sayyed]

Hi,

Can I install subversion system on my own web hosting having WINDOWS and IIS.

Please guide.

Thanks and regards,
ALTAF



  

Re: Subversion on Windows web hosting

[Ryan Schmidt]

On Jan 7, 2011, at 00:03, Altaf-Hussain Sayyed wrote:

> Can I install subversion system on my own web hosting having WINDOWS and IIS.

What you can do with your web hosting account is limited by your web hosting 
provider; if they let you install software, then you can install Subversion. Or 
maybe they already have Subversion installed for you to use. If they let you 
use arbitrary network ports, then you can serve a repository with svnserve on 
port 3690. Subversion cannot be served using IIS; if you want to serve a 
repository using WebDAV (i.e. the http or https protocol), then you must 
install the Apache 2 web server; possibly, this could live alongside your 
existing IIS web server, if you want it to.