Problem in setting Subversion SVN with Windows Domain users authentication

[Subodh Singh]

Hi,

 

How do I integrate Domain uses with SubversionSVN. I am able to get
repository as SVN authentication. 

 

Thanks

Subodh

 

RE: how to compare an exported file (or set of files) against the repository?

[REEDICK, ANDREW]

Unless you exported multiple revisions, you shouldn't need more than a few 
positive matches to determine the revision.

First, compare the tree structure against the repository.  You'll want to avoid 
researching moved files, and this will help you narrow down your search.

Second, 'svn export' seems to preserve timestamps on the exported files.  You 
can check 'svn log' for a matching timestamp for that file.

Then once you have enough fingerprints to id the export revision, you can do a 
generic tree comparison to find changed and/or moved files.


> -Original Message-
> From: Mertens, Bram [mailto:merte...@mazdaeur.com]
> 
> 
> Is this possible without looping through all the revisions and calculating
> checksums?
> The problem with appraoch besides the time it would take is that it would
> obviously not catch files that are not 100% identical to the files in that
> revision.
> 
> Thanks in advance for any pointer that would help in this.
> 

Re: Subversion and Remote Repository Synchronization

[Mark Phippard]

On Thu, Oct 6, 2011 at 4:23 PM, David Weintraub  wrote:
>> On Thu, Oct 6, 2011 at 1:51 PM, Daniel Shahaf  
>> wrote:
>>
 >> What about using "svngit"? We could have an automated process that
 >> pulls data from the Subversion repository in the U.S. and creates a
 >> local Git repository in India using "svngit'. This could be done when
 >> there's no one in the Indian office. Developers could then checkout
 >> and commit their changes to their local Git repository. In the middle
 >> of the night, the Git repository could then push its changes to
 >> Subversion using "gitsvn" Is this a possibility?
>
> On Thu, Oct 6, 2011 at 3:49 PM, Les Mikesell  wrote:
>> I don't have experience with using git-svn myself, but it seems to be
>> designed to handle that scenario.
>
> Svn-git was mainly designed to allow you to checkpoint your work
> without checking in code you know might not work.
>
> What I am thinking is something a bit more radical: Using Git as a
> local repository for a remote Subversion repository. Now, you're
> talking about 10 to 20 or more users in your remote site using Git,
> pushing their changes to the local central Git repository, and then
> having that central Git repository sync itself back to the Subversion
> repository. You're hope is that the site that has the Subversion
> repository isn't doing to many changes while the remote site is
> active. And, the remote site isn't active while the local site is
> committing changes into Subversion.

Have you seen this?

http://subgit.com/

It is something the guys that make SVNKit have been working on.


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Subversion and Remote Repository Synchronization

[David Weintraub]

> On Thu, Oct 6, 2011 at 1:51 PM, Daniel Shahaf  wrote:
>
>>> >> What about using "svngit"? We could have an automated process that
>>> >> pulls data from the Subversion repository in the U.S. and creates a
>>> >> local Git repository in India using "svngit'. This could be done when
>>> >> there's no one in the Indian office. Developers could then checkout
>>> >> and commit their changes to their local Git repository. In the middle
>>> >> of the night, the Git repository could then push its changes to
>>> >> Subversion using "gitsvn" Is this a possibility?

On Thu, Oct 6, 2011 at 3:49 PM, Les Mikesell  wrote:
> I don't have experience with using git-svn myself, but it seems to be
> designed to handle that scenario.

Svn-git was mainly designed to allow you to checkpoint your work
without checking in code you know might not work.

What I am thinking is something a bit more radical: Using Git as a
local repository for a remote Subversion repository. Now, you're
talking about 10 to 20 or more users in your remote site using Git,
pushing their changes to the local central Git repository, and then
having that central Git repository sync itself back to the Subversion
repository. You're hope is that the site that has the Subversion
repository isn't doing to many changes while the remote site is
active. And, the remote site isn't active while the local site is
committing changes into Subversion.

I like the Perforce proxy. It's practically invisible to the user and
really speeds things up.

I was thinking that I could script a MultiSite solution with
Subversion without too much difficulty. I started working on the
project and realized that there was a major problem. With ClearCase
MultiSite, your repositories will match version for version. In my
Subversion imitation, I was getting the sync done correctly, and the
trees and changes matched. However, the revision numbering was off
between the two sites.

Since most people use the Subversion revision numbering as an
alternative to tags, the mismatch in revision numbers would be
unacceptable. And, the "svn logs" don't match, so it becomes difficult
to match the history.

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

Re: Subversion and Remote Repository Synchronization

[Les Mikesell]

On Thu, Oct 6, 2011 at 1:51 PM, Daniel Shahaf  wrote:

>> >> What about using "svngit"? We could have an automated process that
>> >> pulls data from the Subversion repository in the U.S. and creates a
>> >> local Git repository in India using "svngit'. This could be done when
>> >> there's no one in the Indian office. Developers could then checkout
>> >> and commit their changes to their local Git repository. In the middle
>> >> of the night, the Git repository could then push its changes to
>> >> Subversion using "gitsvn" Is this a possibility?
>> >
>> > And what do you do when the push step fails due to the Subversion
>> > repository having changed after the pull?
>>
>> I think you are supposed to branch for your local git work, then
>> 'rebase' the svn copy (equivalent to upate) before merging your branch
>> and using dcommit to push it back to the svn master.  Conceptually it
>> shouldn't be different than the repository changing compared to an
>> outstanding modified svn working copy.
>>
>
> I thought David described a solution that implied machine merging, so
> I wanted to point out that that Doesn't Always Work.  Of course, if
> a developer does the merging then my concern doesn't apply.

I don't have experience with using git-svn myself, but it seems to be
designed to handle that scenario.  However, I think the main value
would be the ability to do more work 'offline' with the commits back
to svn done in batches.  If you are trying to coordinate changes
between different teams working on the same project, you'll probably
want frequent commits anyway.   If the work is mostly/all being done
at the remote site you could move the live repository there and use an
automated snvsync to keep a local read-only copy as a backup and for
test builds.

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

Re: svn: generic failure

[Stefan Sperling]

On Thu, Oct 06, 2011 at 11:55:34AM +0200, frantisek holop wrote:
> hi there,
> 
> (i am not subscribed to the list, please cc: me with your answer)
> 
> the problem in a nutshell:
> 
> repository$ svn up
> svn: generic failure
> 
> i am having a hard time tracking this down, so any pointers
> are appreciated.

This turned out to be a problem in OpenBSD's SASL port (see discussion
with similar date and subject on openbsd's ports@ list).

I improved the error message
(see http://svn.apache.org/viewvc?view=revision&revision=1179767)
and will nominate this change for 1.7.1.

Thanks for your report.

Re: Subversion and Remote Repository Synchronization

[Daniel Shahaf]

Les Mikesell wrote on Thu, Oct 06, 2011 at 13:25:58 -0500:
> On Thu, Oct 6, 2011 at 12:55 PM, Daniel Shahaf  
> wrote:
> > David Weintraub wrote on Thu, Oct 06, 2011 at 12:22:33 -0400:
> >> What about using "svngit"? We could have an automated process that
> >> pulls data from the Subversion repository in the U.S. and creates a
> >> local Git repository in India using "svngit'. This could be done when
> >> there's no one in the Indian office. Developers could then checkout
> >> and commit their changes to their local Git repository. In the middle
> >> of the night, the Git repository could then push its changes to
> >> Subversion using "gitsvn" Is this a possibility?
> >
> > And what do you do when the push step fails due to the Subversion
> > repository having changed after the pull?
> 
> I think you are supposed to branch for your local git work, then
> 'rebase' the svn copy (equivalent to upate) before merging your branch
> and using dcommit to push it back to the svn master.  Conceptually it
> shouldn't be different than the repository changing compared to an
> outstanding modified svn working copy.
> 

I thought David described a solution that implied machine merging, so
I wanted to point out that that Doesn't Always Work.  Of course, if
a developer does the merging then my concern doesn't apply.

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

Re: Subversion and Remote Repository Synchronization

[Les Mikesell]

On Thu, Oct 6, 2011 at 12:55 PM, Daniel Shahaf  wrote:
> David Weintraub wrote on Thu, Oct 06, 2011 at 12:22:33 -0400:
>> What about using "svngit"? We could have an automated process that
>> pulls data from the Subversion repository in the U.S. and creates a
>> local Git repository in India using "svngit'. This could be done when
>> there's no one in the Indian office. Developers could then checkout
>> and commit their changes to their local Git repository. In the middle
>> of the night, the Git repository could then push its changes to
>> Subversion using "gitsvn" Is this a possibility?
>
> And what do you do when the push step fails due to the Subversion
> repository having changed after the pull?

I think you are supposed to branch for your local git work, then
'rebase' the svn copy (equivalent to upate) before merging your branch
and using dcommit to push it back to the svn master.  Conceptually it
shouldn't be different than the repository changing compared to an
outstanding modified svn working copy.

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

Re: Subversion and Remote Repository Synchronization

[Daniel Shahaf]

David Weintraub wrote on Thu, Oct 06, 2011 at 12:22:33 -0400:
> What about using "svngit"? We could have an automated process that
> pulls data from the Subversion repository in the U.S. and creates a
> local Git repository in India using "svngit'. This could be done when
> there's no one in the Indian office. Developers could then checkout
> and commit their changes to their local Git repository. In the middle
> of the night, the Git repository could then push its changes to
> Subversion using "gitsvn" Is this a possibility?

And what do you do when the push step fails due to the Subversion
repository having changed after the pull?

Re: Subversion and Remote Repository Synchronization

[Mark Phippard]

On Thu, Oct 6, 2011 at 12:22 PM, David Weintraub  wrote:
> Let's say I have a team in the U.S. where my Subversion repository is
> kept, and I have a remote team in India. The remote team in India is
> complaining about the length of time for checkouts and commits. Is
> there a solution to this particular issue in Subversion?
>
> I could create a local Svnsync repository, but that's read-only. Is it
> possible for the Indian users to checkout from the SvnSync repository,
> then do a relocate to the U.S. main repository, and then check in
> their changes? Would this be any faster than directly checking out
> from the U.S. repository?

There is a simple low-tech option.  Setup a CRON job that does svn
update on a local checkout, tars the result and posts it on a server
in the LAN in India.  When developers need to do a checkout they can
download and extract the tar and just run svn update to catch up to
HEAD quickly.  They can easily use switch to change to a branch pretty
efficiently.  I know a lot of users that use this successfully.

If you use Apache, you can use the WebDAV proxy.  This takes your
svnsync idea a step further by making the local server act as a proxy
for the master on write operations.  There are several advantages of
this approach over your suggestion.

1) Developers do not need to use switch.  They just checkout from
their local mirror and work as normal.  The mirror handles proxying
requests back to the master when needed.

2) Since developers do not need to use switch, they can use the mirror
for more than checkout.  Commands like log/diff/update/switch/merge
are all processed by their local mirror and give the performance
benefits from this,

This is what the ASF uses for their repository.  They have a mirror in
Europe that committers in Europe connect through when working with the
ASF repository.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Subversion and Remote Repository Synchronization

[Ed]

Subversion is not disributed - try svnsync for a while, most of the
pain should go away
otherwise check out http://www.wandisco.com/

On Thu, Oct 6, 2011 at 9:22 AM, David Weintraub  wrote:
> Let's say I have a team in the U.S. where my Subversion repository is
> kept, and I have a remote team in India. The remote team in India is
> complaining about the length of time for checkouts and commits. Is
> there a solution to this particular issue in Subversion?
>
> I could create a local Svnsync repository, but that's read-only. Is it
> possible for the Indian users to checkout from the SvnSync repository,
> then do a relocate to the U.S. main repository, and then check in
> their changes?

the checkin is "proxied" by the mirror - don't mess up the WC with a relocate

 Would this be any faster than directly checking out
> from the U.S. repository?
>
> What about using "svngit"? We could have an automated process that
> pulls data from the Subversion repository in the U.S. and creates a
> local Git repository in India using "svngit'. This could be done when
> there's no one in the Indian office. Developers could then checkout
> and commit their changes to their local Git repository. In the middle
> of the night, the Git repository could then push its changes to
> Subversion using "gitsvn" Is this a possibility?
>
> I know other revision control systems have a variety of methods in
> handling this issue:
>
> * Git, of course, can easily create a local Indian copy of the
> repository, and everyone there can checkout and commit to that local
> repository. Changes in the local Indian Git repository can then be
> pushed to the U.S. main Git repository.
>
> * Perforce can use repository proxies
> .
> The proxies will deliver local copies of a requested checkout if it
> exists, or fetch the copy from the remote server when necessary. There
> is no synchronization issues, but later checkouts are fairly fast. In
> fact, many sites have a nightly process that pre-fetches the data from
> the remote repository to the proxy since the first request for a
> particular version of a file will take a long time.
>
> * ClearCase has the most interesting (and complex) solution. ClearCase
> has something called MultiSite. With MultiSite you create a local copy
> of the remote repository. This is similar to SVNSync. However, what
> MultiSite does is only give one site read-write permission on a per
> branch basis. Other sites will be able to see that branch, but it will
> be read-only. Instead they'll have their own read-write branch (which
> is read-only to everyone else).
>
> For example, I have a site in India and in the U.S. My repository is
> in the U.S., with MultiSite, I create a duplicate repository in India.
> My U.S. office can read and write to our "trunk" (/main in ClearCase
> parlance), but the India office can only read data from the "trunk".
> The Indian office creates a branch based upon the trunk called
> "india".  The Indian office can read and write to that branch. The
> U.S. office only has read capabilities on this branch.
>
> This will allow the U.S. office to merge the changes from the "india"
> branch to "trunk" and allow the Indian office to synchronize the U.S.
> changes from "trunk" to the "india" branch.
>
> I was thinking of implementing some sort of MultiSite in Subversion,

that would be WANdisco

> but although the branches would "match", there would be an issue with
> revision numbering. For example, in ClearCase, both the Indian office
> and the U.S. office would be talking about the same version when they
> talk about revision #6 of a particular file on the trunk or version
> #24 of a particular file on the Indian branch. This is because each
> file and each branch has their own numbering scheme. However, in
> Subversion, since the whole repository is revisioned, what would be
> revision 6 of /module/trunk/build.xml in the U.S. could be revision 15
> in India.
>
> Any ideas?
>
> --
> David Weintraub
> qazw...@gmail.com
>

Subversion and Remote Repository Synchronization

[David Weintraub]

Let's say I have a team in the U.S. where my Subversion repository is
kept, and I have a remote team in India. The remote team in India is
complaining about the length of time for checkouts and commits. Is
there a solution to this particular issue in Subversion?

I could create a local Svnsync repository, but that's read-only. Is it
possible for the Indian users to checkout from the SvnSync repository,
then do a relocate to the U.S. main repository, and then check in
their changes? Would this be any faster than directly checking out
from the U.S. repository?

What about using "svngit"? We could have an automated process that
pulls data from the Subversion repository in the U.S. and creates a
local Git repository in India using "svngit'. This could be done when
there's no one in the Indian office. Developers could then checkout
and commit their changes to their local Git repository. In the middle
of the night, the Git repository could then push its changes to
Subversion using "gitsvn" Is this a possibility?

I know other revision control systems have a variety of methods in
handling this issue:

* Git, of course, can easily create a local Indian copy of the
repository, and everyone there can checkout and commit to that local
repository. Changes in the local Indian Git repository can then be
pushed to the U.S. main Git repository.

* Perforce can use repository proxies
.
The proxies will deliver local copies of a requested checkout if it
exists, or fetch the copy from the remote server when necessary. There
is no synchronization issues, but later checkouts are fairly fast. In
fact, many sites have a nightly process that pre-fetches the data from
the remote repository to the proxy since the first request for a
particular version of a file will take a long time.

* ClearCase has the most interesting (and complex) solution. ClearCase
has something called MultiSite. With MultiSite you create a local copy
of the remote repository. This is similar to SVNSync. However, what
MultiSite does is only give one site read-write permission on a per
branch basis. Other sites will be able to see that branch, but it will
be read-only. Instead they'll have their own read-write branch (which
is read-only to everyone else).

For example, I have a site in India and in the U.S. My repository is
in the U.S., with MultiSite, I create a duplicate repository in India.
My U.S. office can read and write to our "trunk" (/main in ClearCase
parlance), but the India office can only read data from the "trunk".
The Indian office creates a branch based upon the trunk called
"india".  The Indian office can read and write to that branch. The
U.S. office only has read capabilities on this branch.

This will allow the U.S. office to merge the changes from the "india"
branch to "trunk" and allow the Indian office to synchronize the U.S.
changes from "trunk" to the "india" branch.

I was thinking of implementing some sort of MultiSite in Subversion,
but although the branches would "match", there would be an issue with
revision numbering. For example, in ClearCase, both the Indian office
and the U.S. office would be talking about the same version when they
talk about revision #6 of a particular file on the trunk or version
#24 of a particular file on the Indian branch. This is because each
file and each branch has their own numbering scheme. However, in
Subversion, since the whole repository is revisioned, what would be
revision 6 of /module/trunk/build.xml in the U.S. could be revision 15
in India.

Any ideas?

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

RE: Problem when commiting with svnmirrors

[Dominik Psenner]

I’m unsure if this really matters, but there exists a commercial product
that enables svn morroring with writeable mirrors by using the paxos
algorithm.

 

  _  

From: yasith tharindu [mailto:yasithu...@gmail.com] 
Sent: Thursday, October 06, 2011 1:03 PM
To: Thorsten Schöning
Cc: users@subversion.apache.org
Subject: Re: Problem when commiting with svnmirrors

 

Actually mirror is read only. Im sorry if i make you misunderstand. [1] is
the configurations i made. Mirror use the "SVNMasterURI"  directive.

[1] http://www.yasith.info/2011/08/comprehensive-svn-mirror.html

Thanks..



2011/10/4 Thorsten Schöning 

Guten Tag yasith tharindu,
am Dienstag, 4. Oktober 2011 um 14:35 schrieben Sie:


> We have configured svn mirrors and when there are some big commits passing
> through secondary servers to the master, some times gives following error.
> Mirror is configured as following diagram[1]. Is there a solution for
this?

Are you really sure that you use svnsync that way? Normally
svnsync-mirros must be read only du to conflicting version
generations. In your case a big local commit would intefere with a
public commit and the time it needs to get the local commit to the
main repo and the newly public commit to the mirror.

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig

Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoen...@am-soft.de
Web: http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow




-- 
Thanks..
Regards...

Blog: http://www.yasith.info
Twitter : http://twitter.com/yasithnd
LinkedIn : http://www.linkedin.com/in/yasithnd

Re: Crash report from TortoiseSVN

[Andy Levy]

On Thu, Oct 6, 2011 at 08:26, Aleksa Todorovic  wrote:
>
> On Thu, Oct 6, 2011 at 13:02, Andy Levy  wrote:
>>
>> On Thu, Oct 6, 2011 at 06:22, Aleksa Todorovic  wrote:
>> > ---
>> > Subversion Exception!
>> > ---
>> > Subversion encountered a serious problem.
>> > Please take the time to report this on the Subversion mailing list
>> > (users@subversion.apache.org)
>> > 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
>> >
>> > 'C:\Users\kueng\nightlybuilds\latest\TortoiseSVN\ext\subversion\subversion\libsvn_subr\dirent_uri.c'
>> > line 1596: assertion failed (! svn_path_is_url(relative))
>> > ---
>> > OK
>> > ---
>> >
>> > I'm on Windows XP, TortoiseSVN 1.6.99, build 22019 - 32bit dev -
>> > 2011/09/22
>> > 12:01:54
>> > Subversion 1.7.0 -dev
>> > apr 1.4.5
>> > apr-utils 1.3.12
>> > neon 0.29.6
>> > OpenSSL 1.0.0d 9 Feb 2011
>> > zlib 1.2.5
>> > Steps for the crash:
>> > 1. I opened Show Log dialog on my checkout
>> > 2. Selected last revesion (I committed it)
>> > 3. Right-clicked on the file I committed (only on file was in commit),
>> > and
>> > chose "Revert changes from this revision"
>> > 4. There happens crash!
>> > Hope this helps
>>
>> Please try with the latest nightly build of TortoiseSVN and/or the
>> latest Subversion. Your build is 2 weeks old.
>
> Tried with lates nightly build (r22055), it still crashes. Can you (or
> someone else) point me to Windows svn nightly build binaries so I can try
> with them?

Stefan has builds available alongside the TSVN builds.
http://nightlybuilds.tortoisesvn.net/latest/win32/full/

Re: Crash report from TortoiseSVN

[Aleksa Todorovic]

On Thu, Oct 6, 2011 at 13:02, Andy Levy  wrote:

> On Thu, Oct 6, 2011 at 06:22, Aleksa Todorovic  wrote:
> > ---
> > Subversion Exception!
> > ---
> > Subversion encountered a serious problem.
> > Please take the time to report this on the Subversion mailing list
> > (users@subversion.apache.org)
> > 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
> >
> 'C:\Users\kueng\nightlybuilds\latest\TortoiseSVN\ext\subversion\subversion\libsvn_subr\dirent_uri.c'
> > line 1596: assertion failed (! svn_path_is_url(relative))
> > ---
> > OK
> > ---
> >
> > I'm on Windows XP, TortoiseSVN 1.6.99, build 22019 - 32bit dev -
> 2011/09/22
> > 12:01:54
> > Subversion 1.7.0 -dev
> > apr 1.4.5
> > apr-utils 1.3.12
> > neon 0.29.6
> > OpenSSL 1.0.0d 9 Feb 2011
> > zlib 1.2.5
> > Steps for the crash:
> > 1. I opened Show Log dialog on my checkout
> > 2. Selected last revesion (I committed it)
> > 3. Right-clicked on the file I committed (only on file was in commit),
> and
> > chose "Revert changes from this revision"
> > 4. There happens crash!
> > Hope this helps
>
> Please try with the latest nightly build of TortoiseSVN and/or the
> latest Subversion. Your build is 2 weeks old.
>

Tried with lates nightly build (r22055), it still crashes. Can you (or
someone else) point me to Windows svn nightly build binaries so I can try
with them?

Re: Crash report from TortoiseSVN

[Andy Levy]

On Thu, Oct 6, 2011 at 06:22, Aleksa Todorovic  wrote:
> ---
> Subversion Exception!
> ---
> Subversion encountered a serious problem.
> Please take the time to report this on the Subversion mailing list
> (users@subversion.apache.org)
> 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
> 'C:\Users\kueng\nightlybuilds\latest\TortoiseSVN\ext\subversion\subversion\libsvn_subr\dirent_uri.c'
> line 1596: assertion failed (! svn_path_is_url(relative))
> ---
> OK
> ---
>
> I'm on Windows XP, TortoiseSVN 1.6.99, build 22019 - 32bit dev - 2011/09/22
> 12:01:54
> Subversion 1.7.0 -dev
> apr 1.4.5
> apr-utils 1.3.12
> neon 0.29.6
> OpenSSL 1.0.0d 9 Feb 2011
> zlib 1.2.5
> Steps for the crash:
> 1. I opened Show Log dialog on my checkout
> 2. Selected last revesion (I committed it)
> 3. Right-clicked on the file I committed (only on file was in commit), and
> chose "Revert changes from this revision"
> 4. There happens crash!
> Hope this helps

Please try with the latest nightly build of TortoiseSVN and/or the
latest Subversion. Your build is 2 weeks old.

Re: Problem when commiting with svnmirrors

[yasith tharindu]

Actually mirror is read only. Im sorry if i make you misunderstand. [1] is
the configurations i made. Mirror use the "SVNMasterURI"  directive.

[1] http://www.yasith.info/2011/08/comprehensive-svn-mirror.html

Thanks..


2011/10/4 Thorsten Schöning 

> Guten Tag yasith tharindu,
> am Dienstag, 4. Oktober 2011 um 14:35 schrieben Sie:
>
> > We have configured svn mirrors and when there are some big commits
> passing
> > through secondary servers to the master, some times gives following
> error.
> > Mirror is configured as following diagram[1]. Is there a solution for
> this?
>
> Are you really sure that you use svnsync that way? Normally
> svnsync-mirros must be read only du to conflicting version
> generations. In your case a big local commit would intefere with a
> public commit and the time it needs to get the local commit to the
> main repo and the newly public commit to the mirror.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning
> AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
>
> Telefon: Potsdam: 0331-743881-0
> E-Mail:  tschoen...@am-soft.de
> Web: http://www.am-soft.de
>
> AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
> Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
>
>


-- 
Thanks..
Regards...

Blog: http://www.yasith.info
Twitter : http://twitter.com/yasithnd
LinkedIn : http://www.linkedin.com/in/yasithnd

Crash report from TortoiseSVN

[Aleksa Todorovic]

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
(users@subversion.apache.org)
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
'C:\Users\kueng\nightlybuilds\latest\TortoiseSVN\ext\subversion\subversion\libsvn_subr\dirent_uri.c'
line 1596: assertion failed (! svn_path_is_url(relative))
---
OK
---

I'm on Windows XP, TortoiseSVN 1.6.99, build 22019 - 32bit dev - 2011/09/22
12:01:54
Subversion 1.7.0 -dev
apr 1.4.5
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.0d 9 Feb 2011
zlib 1.2.5

Steps for the crash:
1. I opened Show Log dialog on my checkout
2. Selected last revesion (I committed it)
3. Right-clicked on the file I committed (only on file was in commit), and
chose "Revert changes from this revision"
4. There happens crash!

Hope this helps

svn: generic failure

[frantisek holop]

hi there,

(i am not subscribed to the list, please cc: me with your answer)

the problem in a nutshell:

repository$ svn up
svn: generic failure

i am having a hard time tracking this down, so any pointers
are appreciated.

a bit more information:

the repo is on debian (svnserve in its simplest configuration):

%<---
$ svn --version
svn, version 1.6.12 (r955767)
   compiled May 31 2011, 16:12:12

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - handles 'http' scheme
  - handles 'https' scheme
%<---



the client is on openbsd:

%<---
$ svn --version
svn, version 1.6.17 (r1128011)
   compiled Sep 24 2011, 02:22:43

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.apache.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
%<---


the same version combination (server: 1.6.12, client: 1.6.17)
is confirmed to work with a client on fedora.

previous openbsd clients worked fine, and there was no change
in the configuration.  i also tried removing $HOME/.subversion
and i was not asked for credentials, anything.  the same
message all the time.

i am looking for a switch (or a way) that would make subversion
overly verbose so i could make a guess what is going wrong
and where.

-f
-- 
the borg assimilated my race & all i got was this t-shirt

Re: Subversion 1.6.17 installation

[Mat Booth]

On 5 October 2011 16:08, Kalimuthu Samayan  wrote:
> Hi,
> Having trouble in installing Subversion 1.6.17 rpm since it is looking
> for dependency library files like libapr-1.so, libaprutil-1.so and
> libneon.so. Is that any one give me the URL to download the subversion
> 1.6.17 installable.
>
> --
> Regards,
> Muthu
>
> Kalimuthu Samayan
> Mobile: 0044+(0)782 122 7480
>

Try one of the downloads from this page:
http://subversion.apache.org/packages.html

The WANdisco ones should certainly contain everything you need.

Disclaimer: I work for WANdisco, I haven't tried the downloads from
other vendors.

-- 
Mat Booth
Software Engineer
WANdisco, Inc.

http://www.wandisco.com

uberSVN: Subversion Made Easy
http://www.uberSVN.com

Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion

Subversion community
http://www.svnforum.org

Read our blogs
http://blogs.wandisco.com/

Follow us on Twitter
http://www.twitter.com/wandisco

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND
MAY BE PRIVILEGED.  If this message was misdirected, WANdisco, Inc.
and its subsidiaries, ("WANdisco") does not waive any confidentiality
or privilege.  If you are not the intended recipient, please notify us
immediately and destroy the message without disclosing its contents to
anyone.  Any distribution, use or copying of this e-mail or the
information it contains by other than an intended recipient is
unauthorized.  The views and opinions expressed in this e-mail message
are the author's own and may not reflect the views and opinions of
WANdisco, unless the author is authorized by WANdisco to express such
views or opinions on its behalf.  All email sent to or from this
address is subject to electronic storage and review by WANdisco.
Although WANdisco operates anti-virus programs, it does not accept
responsibility for any damage whatsoever caused by viruses being
passed.

Log Entry with no details.

[Jon Hardcastle]

Guys,

I have an oddity I have never seen before. I have a log entry when viewed
from tortoise that has no author, actions, message and says (no date) for
the date and time.

any ideas?

-- 
--
N: Jon Hardcastle
E: j...@ehardcastle.com
Q: The avalanche has already started. It is too late for the pebbles to
vote.



-- 
--
N: Jon Hardcastle
E: j...@ehardcastle.com
Q: The avalanche has already started. It is too late for the pebbles to
vote.

RE: Transaction author without requiring password

[Dominik Psenner]

>Yes I did, and this is my deduction also. The user names won't make it
>to the pre-commit unless they're required to authenticate by svnserve
>first.

I'm not an svnserve expert, please don't expect help there. All I can say
is, that you could try to set up subversion within apache. Then it should
work since we're using it daily.