Re: predecessor count for the root node-revision is wrong message

[subu7890]

Hey Jason,
I'm also facing a similar problem.I'm working on a project 
where the svn implementation is on the server side.Since svn 
merge(reintegration only required for my project) reqiures a local working 
copy, I maintain one working copy folder for each user, which I switch to 
the target repository folder(the folder becomes the working copy of the 
repository url of the merge target).When two users, try to merge at the 
very same instant, the merge happens, but the following commit that is 
called inside the same function returns the 'Predescessor Count for the 
root node revision is wrong' for the second user (1st user is able to 
commit properly).I'm invoking a cmd propmt on the server via c# code and 
running the svn commands there.I have gone through your discussions here.I 
found it very technical.Could you Kindly please try to be a bit 
non-technical while replying to my queries?
On Wednesday, 8 February 2012 02:53:10 UTC+5:30, Jason Wong wrote:

> Hello. 
>
> I have recently run into an issue with my subversion system (1.7.1)
> where a specific component I am trying to build has failed. I have
> had sucessful builds of this project before this issue happened since
> we upgraded to 1.7.1. I am currently getting by this by using
> TortoiseSVN 1.7.1 to do the check-in of the files left in the
> workspace. 
>
> This issue seems to be intermittent as it does not happen every time.
> I am using subversion 1.7.1 windows binaries and subversion is
> hosting on Apache 2.2.21. 
>
> I have run "svnadmin verify" against the directory and it has come
> back clean. I was wondering what type of events can cause this to
> happen? Are there any resolutions? 
>
> Here are some entries from the apache log for the last time this
> issue happened. 
>
> The Apache error log shows the following lines: 
>
> [Tue Jan 31 11:37:23 2012] [error] [client 9.31.13.109] Could not
> MERGE resource "/repository/!svn/txn/61847-1bz5" into
> "/repository/project/binaries/release/phase1/iteration/81/trunk
> ". [409, #0]
> [Tue Jan 31 11:37:23 2012] [error] [client 9.31.13.109] An error
> occurred while committing the transaction.  [409, #160004]
> [Tue Jan 31 11:37:23 2012] [error] [client 9.31.13.109] predecessor
> count for the root node-revision is wrong: found 61815,
> committing r61852  [409, #160004]
> [Tue Jan 31 11:37:24 2012] [error] [client 9.31.13.109] Could not
> fetch resource information.  [404, #0]
> [Tue Jan 31 11:37:24 2012] [error] [client 9.31.13.109] Named
> transaction doesn't exist.  [404, #0] 
>
> The following are from the Apache access log at the same time: 
>
> 9.31.13.109 - username [31/Jan/2012:11:37:22 -0800] "MERGE
> /repository/project/binaries/release/phase1/iteration/81/trunk
> HTTP/1.1" 409 281
> 9.31.13.109 - username [31/Jan/2012:11:37:24 -0800] "DELETE
> /repository/!svn/txn/61847-1bz5 HTTP/1.1" 404 232 
>
> Any help/comments would be appreciated. Thank you. 
>
>
> Jason Wong
>
> 

Repository crash ?

[tetsuya.sakata]

Dear All

Please help me

Following that has occurred

>> C:\>svnadmin recover /Subversion_rep/
>> リポジトリのロックを取得しました。
>> お待ちください。リポジトリの復旧にはいくらか時間がかかります...
>> This application has halted due to an unexpected error.
>> A crash report and minidump file were saved to disk, you can find them here:
>> C:\DOCUME~1\198700~1.DME\LOCALS~1\Temp\svn-crash-log20120314103801.log
>> C:\DOCUME~1\198700~1.DME\LOCALS~1\Temp\svn-crash-log20120314103801.dmp
>> Please send the log file to users@subversion.apache.org to help us analyse
>> and solve this problem.
>>
>> NOTE: The crash report and minidump files can contain some sensitive 
>> information
>> (filenames, partial file content, usernames and passwords etc.)


Best regards,
---
tetsuya.sak...@toshiba.co.jp



svn-crash-log20120314103801.log
Description: svn-crash-log20120314103801.log


svn-crash-log20120314103801.dmp
Description: svn-crash-log20120314103801.dmp

RE: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Bert Huijben]

> -Original Message-
> From: David Weintraub [mailto:qazw...@gmail.com]
> Sent: woensdag 14 maart 2012 2:14
> To: Simon Dean
> Cc: Nico Kadel-Garcia; Les Mikesell; Andreas Krey; Giulio Troccoli;
> users@subversion.apache.org
> Subject: Re: Feature request - SVN command to clean a working copy of all
> unversioned and ignored files and directories
> 
> On Mon, Mar 12, 2012 at 1:05 PM, Simon Dean
>  wrote:
> > I suspect TortoiseSVN uses the official Subversion client code under the
> hood.  There's no way they'd
> >  re-implement a whole SVN client from scratch.
> 
> I don't know if Tortoise uses any Subversion command line client code,
> but TortoiseSVN does use the official Subversion API libraries. That's
> what made Subversion so different from CVS. With CVS, you either had
> to reimplement the client yourself, or use the offical CVS client as a
> backend. In Subversion you write your own client, and just use the
> API.
> 
> SVNKit is very different. SVNKit is a Java third party
> reimplementation of the Subversion API, and it's not the complete API
> either. On the other hand, the JavaHL API is a front end to the
> official Subversion API.
> 
> So, it's possible for someone to write a Subversion client that does
> do a "clean up". In fact, the Jenkins Continuous build system has the
> option of doing a thorough clean before doing an update.
> 
> > Other people have commented on the fragility of the "clean" task of a
build
> script.  If you use things like NuGet
> > and Bundler in codebases, they result in multiple directories that need
> "cleaning" - e.g. .\vendor\bundle,
> >  .\packages etc.  You'd be surprised how many unversioned files creep
into a CI
> build when all you're relying
> > on is the build script's "clean" task
> 
> For some reason, the .NET/C# world is behind in this concept when
> compared to the Java world.  By default, there's a "clean" target in
> VisualStudio builds, but it doesn't do a very good job of cleaning.

The standard files produced by Visual Studio should clean up everything, but
if you customize your build you should also customize the cleanup. (This
assumes that you pass the same custom variables to the build as the cleanup
step of MSBuild. If not it cleans up a different build)

And Visual Studio makes adding custom build tasks very easy, but doesn't
provide an easy way to add your own cleanup tasks. (I see too many scripts
that just call things like xcopy and assume this magically cleans up)


When running from Visual Studio it appears that there are leftovers, but
this is mostly because the Intellisense uses the same infrastructure to get
its information.



If you do find places where the common tasks leave files behind please
report them as Microsoft is still taking bug reports for Visual Studio 11.

And if these are Subversion and/or AnkhSVN specific problems please also
send me a mail so I might be able to reach out via a few other channels.

Bert

Re: added branch disappears?

[Geoffrey Myers]

On 03/13/2012 04:51 PM, Bob Archer wrote:

On 03/13/2012 04:14 PM, Bob Archer wrote:

Can anyone shed light on this issue?

1. create new branch 'foo'
2. merge different branch 'bar' into trunk 3. merge trunk into all
other existing branches

Seems that the branch foo disappeared sometime between 2 and 3.  have
the commit email showing I created the branch, so I'm dumbfounded here.

Any insights would be appreciated.


Did you branch to the repository or to the working copy? If you didn't commit

the branch it wouldn't have gone into the repo.

branched to the repository:

svn copy svn+ssh://matrix/team/tree/app/trunk
svn+ssh://matrix/team/tree/trunk/branches/819
-m 'Create a development branch'


We have a commit hook, so it definitely was commited.




Ok, so check the log.. it's either still there or someone deleted it so it 
doesn't show up in HEAD.


I can not find any reference to it in the logs.  Yet, I do have the 
commit email, so I know the commit worked.


This really concerns me.  I can recreate the branch, but really want to 
figure out what happened here.




BOb




--
Until later, Geoffrey

"I predict future happiness for America if they can prevent
the government from wasting the labors of the people under
the pretense of taking care of them."
- Thomas Jefferson

RE: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Simon Dean]

> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: 14 March 2012 10:46
> To: 'David Weintraub'; Simon Dean
> Cc: 'Nico Kadel-Garcia'; 'Les Mikesell'; 'Andreas Krey'; 'Giulio Troccoli';
> users@subversion.apache.org
> Subject: RE: Feature request - SVN command to clean a working copy of all
> unversioned and ignored files and directories
> 
> > -Original Message-
> > From: David Weintraub [mailto:qazw...@gmail.com]
> > Sent: woensdag 14 maart 2012 2:14
> > To: Simon Dean
> > Cc: Nico Kadel-Garcia; Les Mikesell; Andreas Krey; Giulio Troccoli;
> > users@subversion.apache.org
> > Subject: Re: Feature request - SVN command to clean a working copy of
> > all unversioned and ignored files and directories
> >
> > On Mon, Mar 12, 2012 at 1:05 PM, Simon Dean
> >  wrote:
> > > I suspect TortoiseSVN uses the official Subversion client code under
> > > the
> > hood.  There's no way they'd
> > >  re-implement a whole SVN client from scratch.
> >
> > I don't know if Tortoise uses any Subversion command line client code,
> > but TortoiseSVN does use the official Subversion API libraries. That's
> > what made Subversion so different from CVS. With CVS, you either had
> > to reimplement the client yourself, or use the offical CVS client as a
> > backend. In Subversion you write your own client, and just use the
> > API.
> >
> > SVNKit is very different. SVNKit is a Java third party
> > reimplementation of the Subversion API, and it's not the complete API
> > either. On the other hand, the JavaHL API is a front end to the
> > official Subversion API.
> >
> > So, it's possible for someone to write a Subversion client that does
> > do a "clean up". In fact, the Jenkins Continuous build system has the
> > option of doing a thorough clean before doing an update.
> >
> > > Other people have commented on the fragility of the "clean" task of
> > > a
> build
> > script.  If you use things like NuGet
> > > and Bundler in codebases, they result in multiple directories that
> > > need
> > "cleaning" - e.g. .\vendor\bundle,
> > >  .\packages etc.  You'd be surprised how many unversioned files
> > > creep
> into a CI
> > build when all you're relying
> > > on is the build script's "clean" task
> >
> > For some reason, the .NET/C# world is behind in this concept when
> > compared to the Java world.  By default, there's a "clean" target in
> > VisualStudio builds, but it doesn't do a very good job of cleaning.
> 
> The standard files produced by Visual Studio should clean up everything, but
> if you customize your build you should also customize the cleanup. (This
> assumes that you pass the same custom variables to the build as the cleanup
> step of MSBuild. If not it cleans up a different build)
> 
> And Visual Studio makes adding custom build tasks very easy, but doesn't
> provide an easy way to add your own cleanup tasks. (I see too many scripts
> that just call things like xcopy and assume this magically cleans up)
> 
> 
> When running from Visual Studio it appears that there are leftovers, but this
> is mostly because the Intellisense uses the same infrastructure to get its
> information.
> 
> 
> 
> If you do find places where the common tasks leave files behind please
> report them as Microsoft is still taking bug reports for Visual Studio 11.
> 
> And if these are Subversion and/or AnkhSVN specific problems please also
> send me a mail so I might be able to reach out via a few other channels.
> 
>   Bert
> 

I use Rake and Gradle (migrated to Gradle from Maven).  Rake is used for .NET 
codebases and Gradle for Java.   It's very easy for files to slip through a 
"clean" task.  Problem is, a "clean" task doesn't "fail fast"  (an agile 
principle which is also a more general principle: 
http://en.wikipedia.org/wiki/Fail-fast) 

-
The information contained in this message may be CONFIDENTIAL and is intended 
for the addressee only. Any unauthorised use, dissemination of the information, 
or copying of this message is prohibited. If you are not the addressee, please 
notify the sender immediately by return e-mail and delete this message. 
Although this e-mail and any attachments are believed to be free of any virus, 
or other defect which might affect any computer or system into which they are 
received and opened, it is the responsibility of the recipient to ensure that 
they are virus free and no responsibility is accepted by Moneysupermarket.com 
Financial Group Limited for any loss or damage from receipt or use thereof. 
The views expressed are of the individual, and do not necessarily reflect the 
views of Moneysupermarket.com Financial Group Limited.
Moneysupermarket.com Limited is an appointed representative of 
Moneysupermarket.com Financial Group Limited, which is authorised and regulated 
by the Financial Services Authority (FSA FRN 303190). 
Moneysup

Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

['Andreas Krey']

On Wed, 14 Mar 2012 11:52:33 +, Simon Dean wrote:
...
> I use Rake and Gradle (migrated to Gradle from Maven).  Rake is used for .NET 
> codebases and Gradle for Java.   It's very easy for files to slip through a 
> "clean" task. 

Actually the whole notion of a 'clean task' is misleading. Any build
task should automatically contribute to a list of files/directories to
be deleted on 'clean'. After all, e.g. a javac task incarnation knows
what directories it would create, so it can put them on the clean
list. (Speaking for ant here, other build tools may be smarter there.)

> Problem is, a "clean" task doesn't "fail fast"

It can't. Failure there is an omission to do something; which could at best
be noted after the fact by the output of 'svn clean -n' being nonempty.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: added branch disappears?

[Les Mikesell]

On Tue, Mar 13, 2012 at 3:31 PM, Geoffrey Myers
 wrote:
>
>> Did you branch to the repository or to the working copy? If you didn't
>> commit the branch it wouldn't have gone into the repo.
>
>
> branched to the repository:
>
> svn copy svn+ssh://matrix/team/tree/app/trunk
>        svn+ssh://matrix/team/tree/trunk/branches/819
>        -m 'Create a development branch'
>

Are your branches really not parallel to the trunk for the same thing?
  The add and delete of this should show up in the log of
svn+ssh://matrix/team/tree/trunk/branches.

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

Re: svn via ssh to server (not local)

[Ulrich Eckhardt]

Am 13.03.2012 11:14, schrieb Ruslan QuAzI:

How can I use via SSH something like this svn co
svn+ssh://svn.mainhost.org:8890/project/trunk I need sources from
svn://svn.mainhost.org:8890/project/trunk (svnserve -t with local
path not have privileges) Both ssh and svn have non standard ports.
For ssh I change my ~/.ssh/config but how tweak svn to use network
connection instead svnserve -t ? Can't use "ssh -L" in parallel of
sync (sync started from software)


It's a bit unclear what you have and what you want, so let me summarize 
what I understand:

1. You have a host running svnserve on port 8890.
2. You want to connect to that host using SSH and from there access the 
repository.


Actually, the first question is why you want the SSH in between, but I 
guess that the simple reason is that the sources there are private and 
the svnserve isn't accessible from the outside.


Now, using svn+ssh means using SSH to run svnserve on the remote host 
(with the current user's privileges) and then tunneling the traffic 
between svnserve's stdout and the local SVN client. However, this 
doesn't work because your user account on the remote machine doesn't 
have access rights to the files that make up the repository.


There are two ways around this:
1. Get the access rights. This is not a good solution, as direct file 
access means anyone getting into your account can delete the whole 
repository.
2. You can use SSH to tunnel traffic between your local machine and the 
remote machine for some port, e.g. 12345. This means that you then check 
out and commit to svn://localhost:12345/project/trunk. No tweaks to SVN 
are involved then.



I could imagine that the SVN manual also mentions this approach, as it 
is the first approach for any service access when you only have a 
generic SSH access, not just for Subversion.



Good luck!

Uli
**
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein 
sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, 
weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte 
�nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht 
verantwortlich.
**

Cannot accept non-LF line endings in 'svn:ignore' property

[Andreas Krey]

Hi,

the full glory:

  svn: E175008: Commit failed (details follow):
  svn: E175008: At least one property change failed; repository is unchanged
  svn: E175002: Error setting property 'ignore': 
  Cannot accept non-LF line endings in 'svn:ignore' property

For one it would really helpful to know which of the seventeen
svn:ignore properties is the culprit.

But the real strange thing: I did only do a merge; not actually
edit any properties myself.

Is that coming from doing the merge on unix while most other
commits (and all of the properties) are done on windows?

Or is svn 1.7.x (the client) more picky? (But it looks like
a server message.)

Even worse: There are only 0a (LF) line endings in the ignore properties.
No 0d (CR) in sight; at least in the output of 'svn pg svn:ignore'.

Using a 1.7 client on an 1.5.few server.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Cannot accept non-LF line endings in 'svn:ignore' property

[Andreas Krey]

On Wed, 14 Mar 2012 15:33:35 +, Andreas Krey wrote:
...
>   Cannot accept non-LF line endings in 'svn:ignore' property
...
> Even worse: There are only 0a (LF) line endings in the ignore properties.
> No 0d (CR) in sight; at least in the output of 'svn pg svn:ignore'.
> 
> Using a 1.7 client on an 1.5.few server.

..and it's the same with an 1.6.6 client.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: SVN as DMS

[Les Mikesell]

On Wed, Mar 14, 2012 at 11:32 AM, Laura Mohiuddin  wrote:
> Dear Sir/Madam,
>
> My company IBCS-PRIMAX Software (BD) Ltd. (http://www.ibcs-primax.com) is
> looking to install a Document Management System for the organization. I
> suggested SVN, but the DMS should also come with a dashboard and search
> facilities. Is there any way that I can setup subversion to provide me with
> a dashboard and search facilities?
>
> Thank you for your kind cooperation

Something like Fisheye might work, depending on the nature of your documents:
http://www.atlassian.com/software/fisheye/overview

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

Re: SVN as DMS

[Thorsten Schöning]

Guten Tag Laura Mohiuddin,
am Mittwoch, 14. März 2012 um 17:32 schrieben Sie:

> My company IBCS-PRIMAX Software (BD) Ltd. (http://www.ibcs-primax.com) is
> looking to install a Document Management System for the organization. I
> suggested SVN[...]

Sounds like a bad idea to me. While Subversion ma ybe capable of
versioning all your content and even deliver authorization and access
facilities, DMS's provide much more: Configurable processes and
workflows, document format conversion for example to PDF, tagging of
documents, preview for documents, clients/integration for different
purposes like Sharepoint, Office et.c and some even collaboration on
authoring documents. You may don't need all this now, but for future
development in you company in my opinion it would be better to start
with a real DMS right now. Subversion may be better suited for some
kind of backend storage. There are lot of free DMS out there.

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.030-2 1001-310
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: Cannot accept non-LF line endings in 'svn:ignore' property

[Daniel Shahaf]

Andreas Krey wrote on Wed, Mar 14, 2012 at 15:33:35 +0100:
> Hi,
> 
> the full glory:
> 
>   svn: E175008: Commit failed (details follow):
>   svn: E175008: At least one property change failed; repository is unchanged
>   svn: E175002: Error setting property 'ignore': 
>   Cannot accept non-LF line endings in 'svn:ignore' property
> 
> For one it would really helpful to know which of the seventeen
> svn:ignore properties is the culprit.
> 

It's probably an easy patch to libsvn_repos/fs-wrap.c.

> But the real strange thing: I did only do a merge; not actually
> edit any properties myself.
> 

So?  Propchanges are merged too.

> Is that coming from doing the merge on unix while most other
> commits (and all of the properties) are done on windows?
> 
> Or is svn 1.7.x (the client) more picky? (But it looks like
> a server message.)
> 
> Even worse: There are only 0a (LF) line endings in the ignore properties.
> No 0d (CR) in sight; at least in the output of 'svn pg svn:ignore'.
> 

Looking for 0x0a is the right thing, but you want 'propget --strict'.

> Using a 1.7 client on an 1.5.few server.
> 

I think the error message only exists in 1.6+ servers.

> Andreas
> 
> -- 
> "Totally trivial. Famous last words."
> From: Linus Torvalds 
> Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: predecessor count for the root node-revision is wrong message

[Daniel Shahaf]

Jason Wong wrote on Tue, Mar 13, 2012 at 06:57:59 -0700:
> On Fri, Mar 2, 2012 at 8:12 AM, Daniel Shahaf  wrote:
> > Jason Wong wrote on Fri, Mar 02, 2012 at 07:32:38 -0800:
> >> On Fri, Mar 2, 2012 at 2:58 AM, Daniel Shahaf  wrote:
> >> > Jason Wong wrote on Thu, Mar 01, 2012 at 10:01:26 -0800:
> >> >> I have had a developer here create a build of the latest SVN code
> >> >> with your changes you mentioned in r1294470 for the svnadmin verify
> >> >
> >> > Okay, that's great news, for two reasons:
> >> >
> >> > 1. It means building svn on windows isn't as painful as it used to be :)
> >>
> >> Actually, it did take some work to get it going as we did not have
> >> another system available to us and also did not have VC++ 6. We had
> >> to use VS 2010 in order to do this. Also, for the other components
> >> required (python,perl etc), the files after the install were copied
> >> to the workstation to see if it would work as we did not want to
> >> change the current workstation configuration by running the
> >> installers. All in all, it did seem to work.
> >>
> >
> > Okay.  The normal build requires just the *.exe and *.dll files to be
> > placed appropriately (such that the *.exe's and httpd's find their
> > libsvn_* DLL's at runtime) --- it doesn't require Administrator access,
> > for example.
> >
> > To clarify, Perl is only required to build OpenSSL; it is not required
> > to build APR, Neon, or Subversion.
> >
> >> >
> >> > 2. It means I can ask you to build a custom server with the 'inprocess'
> >> > cache disabled, or (if all else fails) to bisect, per my previous email.
> >> >
> >> > One of the things you could try is to disable caching: simply modify
> >> > the function create_cache() in libsvn_fs_fs/caching.c to always return
> >> > NULL in *CACHE_P.  See below for another suggestion.
> >> >
> >> >> command. We have run 'svnadmin verify' against every revision of our
> >> >> hotcopy of our repository taken when we first brought this issue to
> >> >> the forums and are now tracking down each of the revisions to see
> >> >> what actions were being done at those times.
> >> >>
> >> >
> >> > Thanks!  I do hope this work enables us to pinpoint and fix the bug.
> >>
> >> I will be going through the list to see what else was happening at the
> >> same time on the apache server since it was alluded to that there may
> >> be concurrency issues. I know the last two times that this error has
> >> popped up, we had two svn operations starting at around the same time
> >> according to the Apache logs. I will go through the previous apache
> >> history to see if this was always the case or not.
> >>
> >
> > Thanks, looking forward to hear what you come up with.
> >
> > FWIW, Justin's reply suggests that the error was seen on three different
> > platforms --- Windows, Solaris, and FreeBSD --- so that should narrow
> > down the range of possible explanations.
> >
> > (I'll also note that at ASF's installation we are not running into new
> > instances of the bug.)
> 
> Hi Daniel.
> 

Hi.  Sorry for the delay --- was away from svn the last few days.

> I haven't gone through all the cases yet, but I have made progress
> through quite a number of them and a pattern seems to be coming up.
> 

Is it safe to summarize your findings as: in every instance of the bug
(as determined by the new 'svnadmin verify' output), the victim revision
was started whilst (victim-1) was in progress?

That by itself is an everyday occurence, but I think it's nonetheless
a useful piece of information.  I'll try and digest it further later
when I'm less sleepy (it's way past midnight here).

(As I understand ra_dav, the MERGE verb corresponds to the FS level
svn_fs_commit_txn().  Someone please correct me if I'm wrong.)

Thanks,

Daniel

> I have attached 2 txt files. One shows the modified svnadmin verify
> output from the binaries we built. The other shows the revisions and
> what appears to have been occuring at the time of the bug. I figure
> better to provide this now rather than delay any longer for the rest
> of the results.
> 
> I will continue to go through the rest of the events and see if
> there are other differences seen when the issue occurs. I hope
> this information helps.
> 
> Thanks.
> 
> Jason

Re: predecessor count for the root node-revision is wrong message

[Daniel Shahaf]

subu7890 wrote on Tue, Mar 13, 2012 at 21:51:17 -0700:
> Hey Jason,
> I'm also facing a similar problem.I'm working on a project 
> where the svn implementation is on the server side.Since svn 
> merge(reintegration only required for my project) reqiures a local working 
> copy, I maintain one working copy folder for each user, which I switch to 
> the target repository folder(the folder becomes the working copy of the 
> repository url of the merge target).When two users, try to merge at the 
> very same instant, the merge happens, but the following commit that is 
> called inside the same function returns the 'Predescessor Count for the 
> root node revision is wrong' for the second user (1st user is able to 
> commit properly).I'm invoking a cmd propmt on the server via c# code and 
> running the svn commands there.I have gone through your discussions here.I 
> found it very technical.Could you Kindly please try to be a bit 
> non-technical while replying to my queries?

Sure, we will try.  What are your queries?

Right now we don't know what exactly causes the bug; we are still
investigating.  When we make progress or find a fix, we will announce
that.  The best place to watch for such announcements is by registering
to the issue tracker and adding yourself to the CC list on issue #4129
(link below):

http://subversion.tigris.org/issues/show_bug.cgi?id=4129

Please keep discussion of the bug on the mailing list, not on the
issue tracker.

Cheers,

Daniel

> On Wednesday, 8 February 2012 02:53:10 UTC+5:30, Jason Wong wrote:
> 
> > Hello. 
> >
> > I have recently run into an issue with my subversion system (1.7.1)
> > where a specific component I am trying to build has failed. I have
> > had sucessful builds of this project before this issue happened since
> > we upgraded to 1.7.1. I am currently getting by this by using
> > TortoiseSVN 1.7.1 to do the check-in of the files left in the
> > workspace. 
> >
> > This issue seems to be intermittent as it does not happen every time.
> > I am using subversion 1.7.1 windows binaries and subversion is
> > hosting on Apache 2.2.21. 
> >
> > I have run "svnadmin verify" against the directory and it has come
> > back clean. I was wondering what type of events can cause this to
> > happen? Are there any resolutions? 
> >
> > Here are some entries from the apache log for the last time this
> > issue happened. 
> >
> > The Apache error log shows the following lines: 
> >
> > [Tue Jan 31 11:37:23 2012] [error] [client 9.31.13.109] Could not
> > MERGE resource "/repository/!svn/txn/61847-1bz5" into
> > "/repository/project/binaries/release/phase1/iteration/81/trunk
> > ". [409, #0]
> > [Tue Jan 31 11:37:23 2012] [error] [client 9.31.13.109] An error
> > occurred while committing the transaction.  [409, #160004]
> > [Tue Jan 31 11:37:23 2012] [error] [client 9.31.13.109] predecessor
> > count for the root node-revision is wrong: found 61815,
> > committing r61852  [409, #160004]
> > [Tue Jan 31 11:37:24 2012] [error] [client 9.31.13.109] Could not
> > fetch resource information.  [404, #0]
> > [Tue Jan 31 11:37:24 2012] [error] [client 9.31.13.109] Named
> > transaction doesn't exist.  [404, #0] 
> >
> > The following are from the Apache access log at the same time: 
> >
> > 9.31.13.109 - username [31/Jan/2012:11:37:22 -0800] "MERGE
> > /repository/project/binaries/release/phase1/iteration/81/trunk
> > HTTP/1.1" 409 281
> > 9.31.13.109 - username [31/Jan/2012:11:37:24 -0800] "DELETE
> > /repository/!svn/txn/61847-1bz5 HTTP/1.1" 404 232 
> >
> > Any help/comments would be appreciated. Thank you. 
> >
> >
> > Jason Wong
> >
> > 

Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Nico Kadel-Garcia]

On Wed, Mar 14, 2012 at 9:33 AM, Qazwart  wrote:

> What if you deliver your source code *outside* of your revision control
> system? This is quite common for open source projects. If I can't trust the
> build process to do a clean, I'm in trouble.
>
> What if you don't use a build process? Just today, I deployed an
"/etc/yum.repos.d" directory under Subversion, using an "svn checkout
--force" command to put it under Subversion. This is certainly not under a
"build" process, and I would have *loved* to ahve an "svn clean" operation

Re: svn via ssh to server (not local)

[Nico Kadel-Garcia]

On Wed, Mar 14, 2012 at 10:13 AM, Ulrich Eckhardt <
ulrich.eckha...@dominolaser.com> wrote:

> Am 13.03.2012 11:14, schrieb Ruslan QuAzI:
>
>  How can I use via SSH something like this svn co
>> svn+ssh://svn.mainhost.org:**8890/project/trunkI
>>  need sources from
>> svn://svn.mainhost.org:8890/**project/trunk(svnserve
>>  -t with local
>> path not have privileges) Both ssh and svn have non standard ports.
>> For ssh I change my ~/.ssh/config but how tweak svn to use network
>> connection instead svnserve -t ? Can't use "ssh -L" in parallel of
>> sync (sync started from software)
>>
>
> Passwords in clear text are always a problem, and svnserve is *not*
encrypted by default.

Do go look at the Subversin "Red Book" for guidelines. I'm one of the big
proponents of svn+ssh over HTTPS access, because it does not store
passwords in clear text. It usually uses SSH keys, and the "svnserver" and
URL's reflect using a common Subversion user account, typically "svn".

> It's a bit unclear what you have and what you want, so let me summarize
> what I understand:
> 1. You have a host running svnserve on port 8890.
> 2. You want to connect to that host using SSH and from there access the
> repository.
>
> Actually, the first question is why you want the SSH in between, but I
> guess that the simple reason is that the sources there are private and the
> svnserve isn't accessible from the outside.
>
> Now, using svn+ssh means using SSH to run svnserve on the remote host
> (with the current user's privileges) and then tunneling the traffic between
> svnserve's stdout and the local SVN client. However, this doesn't work
> because your user account on the remote machine doesn't have access rights
> to the files that make up the repository.
>
> There are two ways around this:
> 1. Get the access rights. This is not a good solution, as direct file
> access means anyone getting into your account can delete the whole
> repository.
> 2. You can use SSH to tunnel traffic between your local machine and the
> remote machine for some port, e.g. 12345. This means that you then check
> out and commit to svn://localhost:12345/project/**trunk. No tweaks to SVN
> are involved then.
>
>
> I could imagine that the SVN manual also mentions this approach, as it is
> the first approach for any service access when you only have a generic SSH
> access, not just for Subversion.
>
> I do sometimes with that the SVN manual listed the complex example
*first*, so people knew the right way to do it. The shared "svn" user
usually has a $HOME/.ssh/authorized_keys file se tup with restricted
command arguments to the SSH keys, setting the "user" for the svnserve
daemon that is being tunneled. The whole thing is kind of funky to manage,
but it's workable.



>
> Good luck!
>
> Uli
> 
> **
> Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
> 
> **
> Visit our website at http://www.dominolaser.com
> 
> **
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten
> bestimmt und kann vertrauliche Informationen enthalten. Bitte
> benachrichtigen Sie den Absender umgehend, falls Sie nicht der
> beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu
> löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder
> anderweitig benutzt werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie
> nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese
> Folgen nicht verantwortlich.
> 
> **
>
>

Re: SVN as DMS

[Andy Levy]

On Wed, Mar 14, 2012 at 16:31, Thorsten Schöning  wrote:
> Guten Tag Laura Mohiuddin,
> am Mittwoch, 14. März 2012 um 17:32 schrieben Sie:
>
>> My company IBCS-PRIMAX Software (BD) Ltd. (http://www.ibcs-primax.com) is
>> looking to install a Document Management System for the organization. I
>> suggested SVN[...]
>
> Sounds like a bad idea to me. While Subversion ma ybe capable of
> versioning all your content and even deliver authorization and access
> facilities, DMS's provide much more: Configurable processes and
> workflows, document format conversion for example to PDF, tagging of
> documents, preview for documents, clients/integration for different
> purposes like Sharepoint, Office et.c and some even collaboration on
> authoring documents. You may don't need all this now, but for future
> development in you company in my opinion it would be better to start
> with a real DMS right now. Subversion may be better suited for some
> kind of backend storage. There are lot of free DMS out there.

I have to agree. I currently use Subversion to manage a bunch of MS
Office files - project management documentation, technical docs, etc.
It works, but it's far from optimal and really only works well for the
more technical people in the audience. This means that the business
folks still get documents emailed to them when they need them, instead
of going to any kind of portal to find & collaborate on documents on
their own.

Use a system that's built for the job. This is not an area where
Subversion shines, but it's also not designed to be a DMS in the first
place.

Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Les Mikesell]

On Wed, Mar 14, 2012 at 7:29 PM, Nico Kadel-Garcia  wrote:
> On Wed, Mar 14, 2012 at 9:33 AM, Qazwart  wrote:
>>
>> What if you deliver your source code *outside* of your revision control
>> system? This is quite common for open source projects. If I can't trust the
>> build process to do a clean, I'm in trouble.
>>
> What if you don't use a build process? Just today, I deployed an
> "/etc/yum.repos.d" directory under Subversion, using an "svn checkout
> --force" command to put it under Subversion. This is certainly not under a
> "build" process, and I would have *loved* to ahve an "svn clean" operation

So that's what, 500 bytes total if you had just deleted the whole
thing and checked it out clean?

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

Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Nico Kadel-Garcia]

On Wed, Mar 14, 2012 at 9:00 PM, Les Mikesell  wrote:

> On Wed, Mar 14, 2012 at 7:29 PM, Nico Kadel-Garcia 
> wrote:
> > On Wed, Mar 14, 2012 at 9:33 AM, Qazwart  wrote:
> >>
> >> What if you deliver your source code *outside* of your revision control
> >> system? This is quite common for open source projects. If I can't trust
> the
> >> build process to do a clean, I'm in trouble.
> >>
> > What if you don't use a build process? Just today, I deployed an
> > "/etc/yum.repos.d" directory under Subversion, using an "svn checkout
> > --force" command to put it under Subversion. This is certainly not under
> a
> > "build" process, and I would have *loved* to ahve an "svn clean"
> operation
>
> So that's what, 500 bytes total if you had just deleted the whole
> thing and checked it out clean?
>
> In this case, more like 4 K. But it also creates churn and would *break*
yum during that few moments of deletion and re-install, and it would alter
permissions, which is *another* set of issues.

I've actually had this happen in worse fashion in Nagios and httpd, were
configuration files are read out of a directory and any file called *.cfg
for Nagios and *.conf for HTTPD ae read. Debris files are a problem, and
easy for someone to leave behind. And re-deploying /etc/nagios is file
ownership sensitive: typically, the HTTP password file is kept in
/etc/nagios/passwd, and *THAT* needs to be legible to the "apache" user,
although the /etc/nagios directory needs to be legivle to the "nagios" user.

Re-deploy also requires network access. Whatever for? The local working
copy knows its expected state!

Subversion Exception!

[Earl, Michael]

I've searched the archives and this has been reported back as far as 1.7.3 that 
I could see.  I couldn't see that it was reported against 1.7.6 yet.  I deleted 
my entire tree below the root and got the same error again.  Just doing an 
update on Windows 7 64 bit OS.  The repository is approximately 8.1 GB.



---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
'D:\Development\SVN\Releases\TortoiseSVN-1.7.6\ext\subversion\subversion\libsvn_wc\update_editor.c'
line 1583: assertion failed (action == svn_wc_conflict_action_edit || action
== svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace)
---
OK
---