RE: Tigris binary packages for Windows

[Cooke, Mark]

> > -Original Message-
> > From: David Darj [mailto:z...@alagazam.net]
> > Sent: Tuesday, 27 April 2010 6:26 AM
> > To: Cooke, Mark
> > Cc: users@subversion.apache.org; Troy Simpson
> > Subject: Re: Tigris binary packages for Windows
> > 
> > On 2010-04-26 13:58, Cooke, Mark wrote:
> > > Hi David, list,
> > >
> > >
> > > On 2010-04-22 17:06, Cooke, Mark wrote:
> > >
> > > I am resurrecting this thread to ask if anyone has come
> > > forward to volunteer time and/or effort to resurrect the
> > > windoze binaries as we are still on 1.6.6 against 1.6.11
> > > announced a few days ago.
> > >
> > >
> > >
> >  From: David Darj [mailto:z...@alagazam.net]
> >  Sent: 22 April 2010 21:21
> > 
> >  I have built both 1.6.9 and 1.6.11
> >  They are available on my webpage http://alagazam.net
> >  You (and anyone else) is welcome to download and use it.
> > 
> >  The reason I've not announced the release in this (users)
> >  list is that I've hoped some people reading the dev list
> >  (where I did announce it) to download and test it first so
> >  I know my build environment is okey.
> >  As the web page says all test on subversion itself is running
> >  ok., but the bindings has not been tested.
> > 
> > 
> > >>> On 2010-04-23 10:29, Cooke, Mark wrote:
> > >>>
> > >>> You star!  Thanks very much.  I will do some testing with
> > >>> apache 2.2 on windoze using mod_dav_svn and python bindings
> > >>> (to Trac using mod_wsgi) and report back...
> > >>>
> > >>>
> > >> From: David Darj [mailto:z...@alagazam.net]
> > >> Sent: 23 April 2010 18:08
> > >>
> > >> Thanx that would be gr8.
> > >>
> > > So far so good.  Minor points but the ".11" package readme still
> > refers
> > > to ".9"
> > Oh...thats my fault missing to change the version number in 
> some spots.
> > I think I was focused on getting the dependecies versions right.
> > > and some of the files have a different name format from the
> > > tigris packages, e.g.:
> > >
> > >   o svn-python-1.6.6.win32-py2.6.exe
> > >   o svn-win32-1.6.11_py.zip
> > >
> > > ...although I realise one is an installer and the other just the
> > files.
> > >
> > You're right, the first one is an installer and the second 
> one only the
> > files.
> > If you look at tigris download page a bit further down you see the
> > corresponding zip-file there as well.
> > I've just havn't looked into byinding these installers.
> > > Actually, I am unsure about installing the latter, can I just copy
> > the
> > > files over the ones I already have installed or do I need to tell
> > python
> > > about it somehow (probably OT for this list I guess, 
> perhaps Troy is
> > > listening)?
> > >
> > I'm not a python programmer so I don't really know how to 
> install this
> > package (thats why the bindings are not tested).
> > But I suppose you can just extract the file over the old ones.
> > Actually it's not Troy that used to build the python 
> installers, it was
> > DJ Heap, who also used to build the binaries.
> > Maybe he has some info on this matter.
> > >
> > >>> Out of interest, did you use VC6 or VC2008 to compile 
> (there were
> > >>> suggestions earlier in the thread that there might be some
> > potential
> > >>> issues using VC2008 binaries against the official apache build
> > which
> > >>>
> > > I
> > >
> > >>> am required to use here):
> > >>>
> > >>>
> > >> It's built using the good old VC6 like  D.J Heap previously did.
> > >> That way no runtime-dll:s (msvcr*) needs to be 
> distributed with it.
> > >>
> > >>
> > > Excellent, thanks again.
> > >
> > >
> > >>> Also, did you hook up with Troy about the installers ~ I
> > >>> assume that he would be able to put them on tigris at least
> > >>> until we get a new home on apache:
> > >>>
> > >>>
> > >> I havn't had any contact with troy, but this mail is cc:d to
> > >> him as well.  So if he is reading it it would be great if he
> > >> (or anyone else) want to put the there.
> > >>
> > >>
> > > It would be really great if Troy could pick up the baton 
> here as that
> > > would negate my python install issues.
> > >
> > > All the best,
> > >
> > > ~ mark c
> > >
> > 
> -Original Message-
> From: Troy Simpson [mailto:t...@ebswift.com] 
> Sent: 09 May 2010 23:47
> 
> Looks like we're getting closer to official binaries then... 
> As far as the python bindings installer goes, that's something
> I know nothing about.  I have new code for the windows WiX-based
> installer, but thus far haven't had any commit access to place
> the code back in.  The WiX code in the repository has 'issues'.
> 
> Regards,
> 
> Troy
> 
I will try to investigate the python issue but its probably not going to
be this week *sigh*

~ mark c

Re: generic linux binaries

[Ulrich Eckhardt]

On Friday 07 May 2010, Arpad Ilia wrote:
> Is there somewhere a generic linux binary distribution of subversion? One
> that just needs to be unpacked and needs no root privileges on a debian
> system.

No, Subversion is still compiled to CPU-specific code, so there can not be 
generic binaries. That said, you could install SVN e.g. in your home 
directory, it just requires setting PATH and LD_LIBRARY_PATH. You might even 
be able to do so with the normal Debian packages, they are also just archives 
that you can unpack wherever you want.

Uli

-- 
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
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. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: Active-Active Clustering with Subversion

[Hyrum K. Wright]

On Fri, May 7, 2010 at 8:08 PM, BD  wrote:

>
> So the question remains, taking physical restraints out of the question, is
> there anyone out there who knows about managing the risks assocciated with
> having two or more apache/svn nodes accessing repos that are stored on a
> shared NFS storage system, with the SVN DBs using FSFS.


I can't comment on your specific situation, but Subversion repositories are
designed to be accessed by multiple concurrent processes, even if these
processes are located on separate hosts.  When using a single instances
of Apache, for example, multiple requests can often spawn multiple processes
which all interact (correctly) with the Subversion repository.  In addition,
the write-serialization window is relatively small, and writers do not block
readers, so even during long-running parallel commits, read operations will
still work as expected.

Throwing NFS in the mix here may complicate things a bit, but probably not
by much.

-Hyrum

Re: Cannot reintegrate feature branch

[Stefan Sperling]

On Mon, May 10, 2010 at 12:08:15PM +0800, Jean Seurin wrote:
> Hi Stefan,
> 
> mergeinfo properties are exactly as I mention for the file causing problems:
> 
> all and only the 5 files concerned with the problem have been
> commited after a merge from the trunk, empty of modification, but
> with the mergeinfo properties modified as follow:
> added line
> /branches/project-1.13/pathToFile:6266-6372
> 
> This comes from a merge done on the trunk from a Release branch,
> which in turn made its way to the Feature branch in question.

I'm afraid I still think I'm not getting the whole picture, which
makes it hard to understand the problem and help you solve it.

You're giving us hints about what changed in the mergeinfo, but you
aren't providing a complete picture of what the mergeinfo in your
repository really looks like.

Maybe you don't want to or cannot share that information, that's fine.
I think in this case it would be best if you could try to reproduce the
failing merge with a small example script, starting by creating an empty
repository, and running svn commands creating all necessary branches
and doing merges in order to make the problem appear. Then we can reason
about that example and try to find out what is wrong.

You can find an example script you can base your own script on here:
http://subversion.apache.org/docs/community-guide/repro-template.sh

Thanks,
Stefan

Re: Cannot reintegrate feature branch

[Jean Seurin]

Here's the whole thing, minus unconcerned subprojects:

Properties on '$REPO/trunk/project/src/test/resources/log4j.properties':
  svn:mergeinfo

/branches/project-1.10/src/test/resources/log4j.properties:2344-2345,2347,2349,2351,2361,2363,2405

/branches/project-1.13/src/test/resources/log4j.properties:6266-6372

/branches/project-adptation-to-commons-1.1/src/main/resources/log4j.properties:1780-1790
Properties on 
'$REPO/trunk/project/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java':

  svn:mergeinfo

/branches/project-1.10/src/test/java/com/company/client/project/adherent/persistence/AdherentDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405

/branches/project-1.13/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java:6266-6372

/branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/adherent/persistence/AdherentDAOHibernateTest.java:1780-1790
Properties on 
'$REPO/trunk/project/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java':

  svn:mergeinfo

/branches/project-1.10/src/test/java/com/company/client/project/courrier/persistence/CourrierDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405

/branches/project-1.13/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java:6266-6372

/branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/courrier/persistence/CourrierDAOHibernateTest.java:1780-1790
Properties on 
'$REPO/trunk/extranetof/src/main/filters/jse.filter.properties':

  svn:mergeinfo
Properties on '$REPO/trunk/project':
  svn:mergeinfo
/branches/project-1.10:2344-2345,2347,2349,2351,2361,2363,2405
/branches/project-1.13:6266-6372
/branches/project-adptation-to-commons-1.1:1780-1790
Properties on 
'$REPO/trunk/project/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java':

  svn:mergeinfo

/branches/project-1.10/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405

/branches/project-1.13/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java:6266-6372

/branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDAOHibernateTest.java:1780-1790
Properties on 
'$REPO/trunk/project/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java':

  svn:mergeinfo

/branches/project-1.10/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405

/branches/project-1.13/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java:6266-6372

/branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDAOHibernateTest.java:1780-1790


I leave as it is, it probably speaks to you more it does for me.
Here's the list of error produce by 1.6.5 that indicates problematic files:

svn: Reintegrate can only be used if revisions 6336 through 6393 were 
previously merged from $REPO/trunk/project to the reintegrate source, 
but this is not the case:
  
branches/project-dev/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java
Missing ranges: 
/trunk/project/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java:6336-6389
  
branches/project-dev/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java
Missing ranges: 
/trunk/project/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java:6336-6389
  
branches/project-dev/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java
Missing ranges: 
/trunk/project/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java:6336-6389
  
branches/project-dev/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java
Missing ranges: 
/trunk/project/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java:6336-6389

  branches/project-dev/src/test/resources/log4j.properties
Missing ranges: 
/trunk/project/src/test/resources/log4j.properties:6336-6389


Jean

Stefan Sperling wrote:

On Mon, May 10, 2010 at 07:16:37PM +0800, Jean Seurin wrote:
   

Here're the entire mergeinfos in the problematic files,
 


That is still not enough. Subversion considers mergeinfo set
on every file or directory within the merge target when determining
what needs to be merged where. From the target's root

Automatically merge of new binary file.

[Walser Markus]

Hi

Recently I ran into following subversion use case:

1. A new binary file was created in a working copy 1 and *not* added:
   e.g. C:\Test\WorkingCopy1\BinaryFile.pdf 

2. In another working copy 2 of the same repo another binary file with
   the same filename but different content was created and added:
   e.g. C:\TestWorkingCopy2\BinaryFile.pdf. Thereby SVN correctly set
   the mime type to octet.

3. The newly added file was committed in working copy 2.

4. Working copy 1 is updated.


What happens is that SVN reports successful merging of BinaryFile.pdf.

I'd rather expected a conflict with the local BinaryFile.pdf instead of 
trying to merge the binary file.

Is that binary merging behavior as designed or a know bug?

Kind regards, 


Markus

commit failed - No such file or directory

[Vikrama Sanjeeva]

Hi,

1: Did backup of live repository as below:
hot-backup.py --archive-type=zip /my/svn/repo /my/svn/backup

2: Unzipped /my/svn/backup/repo-7.zip

3: checkout /my/svn/backup/repo-7  (using Tortoise)

4: On commit, am getting below error in Apache error_log
###
 Can't create directory /my/svn/backup/repo-7/db/transactions/7-8.txn': No
such file or directory  [500, #2]
###

*httpd.conf*:
 
  DAV svn
 SVNPath /my/svn/backup/repo-7
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /my/svn/users/svn-repo-auth-file
  Require valid-user


Please guide.

Bye,
Viki.

RE: Automatically merge of new binary file.

[Bert Huijben]

> -Original Message-
> From: Walser Markus [mailto:markuswal...@schleuniger.ch]
> Sent: maandag 10 mei 2010 14:25
> To: users@subversion.apache.org
> Subject: Automatically merge of new binary file.
> 
> Hi
> 
> Recently I ran into following subversion use case:
> 
> 1. A new binary file was created in a working copy 1 and *not* added:
>e.g. C:\Test\WorkingCopy1\BinaryFile.pdf
> 
> 2. In another working copy 2 of the same repo another binary file with
>the same filename but different content was created and added:
>e.g. C:\TestWorkingCopy2\BinaryFile.pdf. Thereby SVN correctly set
>the mime type to octet.
> 
> 3. The newly added file was committed in working copy 2.
> 
> 4. Working copy 1 is updated.
> 
> 
> What happens is that SVN reports successful merging of BinaryFile.pdf.
> 
> I'd rather expected a conflict with the local BinaryFile.pdf instead of
> trying to merge the binary file.
> 
> Is that binary merging behavior as designed or a know bug?

Which client did you use? (And which version)

TortoiseSVN always uses "svn update --force" (taking unversioned
obstructions as the new version of the same file) so this would give this
behavior.

Bert

AW: Automatically merge of new binary file.

[Walser Markus]

Hi Bert

Sorry I forgot this important information:

It was Tortoise 1.6.8 Build 19260 (SVN 1.6.11).

Regards,


Markus

-Ursprüngliche Nachricht-
Von: Bert Huijben [mailto:b...@qqmail.nl] 
Gesendet: Montag, 10. Mai 2010 14:53
An: Walser Markus; users@subversion.apache.org
Betreff: RE: Automatically merge of new binary file.



> -Original Message-
> From: Walser Markus [mailto:markuswal...@schleuniger.ch]
> Sent: maandag 10 mei 2010 14:25
> To: users@subversion.apache.org
> Subject: Automatically merge of new binary file.
> 
> Hi
> 
> Recently I ran into following subversion use case:
> 
> 1. A new binary file was created in a working copy 1 and *not* added:
>e.g. C:\Test\WorkingCopy1\BinaryFile.pdf
> 
> 2. In another working copy 2 of the same repo another binary file with
>the same filename but different content was created and added:
>e.g. C:\TestWorkingCopy2\BinaryFile.pdf. Thereby SVN correctly set
>the mime type to octet.
> 
> 3. The newly added file was committed in working copy 2.
> 
> 4. Working copy 1 is updated.
> 
> 
> What happens is that SVN reports successful merging of BinaryFile.pdf.
> 
> I'd rather expected a conflict with the local BinaryFile.pdf instead 
> of trying to merge the binary file.
> 
> Is that binary merging behavior as designed or a know bug?

Which client did you use? (And which version)

TortoiseSVN always uses "svn update --force" (taking unversioned obstructions 
as the new version of the same file) so this would give this behavior.

Bert

RE: Automatically merge of new binary file.

[Bert Huijben]

> -Original Message-
> From: Walser Markus [mailto:markuswal...@schleuniger.ch]
> Sent: maandag 10 mei 2010 14:56
> To: Bert Huijben; users@subversion.apache.org
> Subject: AW: Automatically merge of new binary file.
> 
> Hi Bert
> 
> Sorry I forgot this important information:
> 
> It was Tortoise 1.6.8 Build 19260 (SVN 1.6.11).

In that case I would recommend sending a mail to
users{_AT_}tortoisesvn.tigris.org instead of this list, as it would have to
be fixed in TortoiseSVN.

Thanks,
Bert

> 
> Regards,
> 
> 
> Markus
> 
> -Ursprüngliche Nachricht-
> Von: Bert Huijben [mailto:b...@qqmail.nl]
> Gesendet: Montag, 10. Mai 2010 14:53
> An: Walser Markus; users@subversion.apache.org
> Betreff: RE: Automatically merge of new binary file.
> 
> 
> 
> > -Original Message-
> > From: Walser Markus [mailto:markuswal...@schleuniger.ch]
> > Sent: maandag 10 mei 2010 14:25
> > To: users@subversion.apache.org
> > Subject: Automatically merge of new binary file.
> >
> > Hi
> >
> > Recently I ran into following subversion use case:
> >
> > 1. A new binary file was created in a working copy 1 and *not* added:
> >e.g. C:\Test\WorkingCopy1\BinaryFile.pdf
> >
> > 2. In another working copy 2 of the same repo another binary file with
> >the same filename but different content was created and added:
> >e.g. C:\TestWorkingCopy2\BinaryFile.pdf. Thereby SVN correctly set
> >the mime type to octet.
> >
> > 3. The newly added file was committed in working copy 2.
> >
> > 4. Working copy 1 is updated.
> >
> >
> > What happens is that SVN reports successful merging of BinaryFile.pdf.
> >
> > I'd rather expected a conflict with the local BinaryFile.pdf instead
> > of trying to merge the binary file.
> >
> > Is that binary merging behavior as designed or a know bug?
> 
> Which client did you use? (And which version)
> 
> TortoiseSVN always uses "svn update --force" (taking unversioned
> obstructions as the new version of the same file) so this would give this
> behavior.
> 
>   Bert

AW: Automatically merge of new binary file.

[Walser Markus]

> In that case I would recommend sending a mail to
users{_AT_}tortoisesvn.tigris.org 
> instead of this list, as it would have to be fixed in TortoiseSVN.

Hi Bert,

thank you very much for your answers. As suggested I placed this issue
on 
the tortoise list.

Kind regards,


Markus

RE: Is there any way of extending the set of keywords recognized/expanded by Subversion?

[Edward Knoll]

Not Subversion source control, but some custom SCM/bookkeeping that has been 
built around/on top of Subversion - layers application teams don't have direct 
access.  My (forlorn) hope is there's a way of extending the keywords, so the 
application team could reference these other bookkeeping artifacts as embedded 
keywords and the process/SCM extensions could set those new keywords.

-Original Message-
From: Bob Archer [mailto:bob.arc...@amsi.com] 
Sent: Friday, May 07, 2010 4:19 PM
To: Edward Knoll; users@subversion.apache.org
Subject: RE: Is there any way of extending the set of keywords 
recognized/expanded by Subversion?

> Our company is integrating Subversion into a larger process environment,
> and there are now other kinds of artifacts identifiers associated with our
> repository which are outside of Subversion.   It would be handy if there
> were a way to extend the set of keywords recognized/expanded by Subversion
> to include these external artifact identifiers.

Not that I am aware of. Here we use our build scripts to inject stuff like this 
into the projects and source. The values probably aren't specific to source 
control I assume?

BOb

Re: Active-Active Clustering with Subversion

[BD]

Thanks Hyrum,

Thats a very interesting way of looking at this problem. It does make sense
that multiple commit processes coming from the same machine really wouldnt
be that different from the question I was asking. I guess from here I'll
have to do some testing somehow, with nfs in the mix and see if I can
purposly corrupt data by running many commit requests from two separate
apache nodes. But if what your saying is right, it sounds like i shouldnt
have much in the way of problems.

Thanks again!
B

On Mon, May 10, 2010 at 5:03 AM, Hyrum K. Wright <
hyrum_wri...@mail.utexas.edu> wrote:

>
>
> On Fri, May 7, 2010 at 8:08 PM, BD  wrote:
>
>>
>> So the question remains, taking physical restraints out of the question,
>> is there anyone out there who knows about managing the risks assocciated
>> with having two or more apache/svn nodes accessing repos that are stored on
>> a shared NFS storage system, with the SVN DBs using FSFS.
>
>
> I can't comment on your specific situation, but Subversion repositories are
> designed to be accessed by multiple concurrent processes, even if these
> processes are located on separate hosts.  When using a single instances
> of Apache, for example, multiple requests can often spawn multiple processes
> which all interact (correctly) with the Subversion repository.  In addition,
> the write-serialization window is relatively small, and writers do not block
> readers, so even during long-running parallel commits, read operations will
> still work as expected.
>
> Throwing NFS in the mix here may complicate things a bit, but probably not
> by much.
>
> -Hyrum
>

Re: Active-Active Clustering with Subversion

[kmradke]

BD  wrote on 05/10/2010 09:52:39 AM:
> Thats a very interesting way of looking at this problem. It does 
> make sense that multiple commit processes coming from the same 
> machine really wouldnt be that different from the question I was 
> asking. I guess from here I'll have to do some testing somehow, with
> nfs in the mix and see if I can purposly corrupt data by running 
> many commit requests from two separate apache nodes. But if what 
> your saying is right, it sounds like i shouldnt have much in the way
> of problems.

Not to get offtrack again, but have you ever thought of just using
more cores/cpus in one physical server instead of multiple physical
servers?  Yes, you lose hardware failover, but you do not risk any
potential bizarre data corruption issues caused by multiple writers
on NFS.

I have seen near saturation on dual 1Gb network links on a dual
cpu/dual core svn server without using NFS for storage.  (Disk
I/O is on a separate SAN fiber network.)  I would hate to go
back to network based Disk I/O...

Kevin R.

How do I determine if svn:mergeinfo is corrupt and how would I fix it.

[Peter Kahn]

I suspect I have corrupt mergeinffo but I'm not sure. Does anyone know how
I'd make a determination and what resources are out there to help fix
problems?

Here’s the issue. My team recently moved to agile and uses feature branches
(story branches really) where different teams work on the same sources
concurrently. As the story achieves a high state of readiness the team
merges to trunk. The merges are taking days or weeks due to missing changes,
unexpected changes, and conflicts. We are talking about teams of 5-10 people
and the effort/churn seems way to high.

People use the this merge pattern

a) PULL - merge trunk-to-branch, resolve, test, commit

b) PUSH - merge branch-to-trunk, resolve, test, commit

c) Recreate branch (or usually create new story branch and drop old since
it's done)

By the end of this the branch and trunk should be in alignment.

*Problems we are seeing:*

   1. changes not reported during trunk-to-branch merge show up in
   subsequent branch-to-trunk
   2. conflicts on svn:mergefinfo properties during merge
   3. file missing, but local edit on new file added in branch and pushed to
   trunk
   4. incoming + local delete (file deleted on trunk and branch shows as
   conflict)

(1) Should not be happening. The pull from branch to trunk should put the
two in sync for all changes already on trunk. The changes in branch-to-trunk
merge are changes that happened on the trunk. So in the first merge they
should have propagated to branch but didn’t. This points to corruption in
mergeinfo data which would “hide” trunk changes.

(2) Should not be happening. SVN should be managing the changes in the merge
tracking. This also points to corruption in the mergeinfo data

(3) Should not be happening. This is a case of a new file added on branch.
It should show up as a new file added to trunk. This also points to
corruption in the merge info data.

(4) I believe this is a SVN bug and that we can’t fix this. Still if this
were our only problem I'd be happy

We are currently on svn 1.5.x server with clients using svn 1.6.x and
svn+ssh for connecting. We plan to go up to the latest and greatest SVN
since some fixes may impact our problems.

Still, it sure looks like our mergeinfo data is wrong.

   - Merges that don't report all changes
   - Conflicts in merge of mergeinfo properites

Any good places for me to start looking?


FYI, I also posted this to
Stackoverflow,
but thus far "move to git" has been the only response and that's not really
an option for me at present.



-- 
Peter Kahn
citizenk...@gmail.com
pkahnp...@aim
http://www.google.com/profiles/citizenkahn
Awareness - Intention - Action

Re: Cannot reintegrate feature branch

[Stefan Sperling]

On Mon, May 10, 2010 at 07:45:07PM +0800, Jean Seurin wrote:
> Here's the whole thing, minus unconcerned subprojects:
> 
> Properties on '$REPO/trunk/project/src/test/resources/log4j.properties':
>   svn:mergeinfo
> /branches/project-1.10/src/test/resources/log4j.properties:2344-2345,2347,2349,2351,2361,2363,2405
> /branches/project-1.13/src/test/resources/log4j.properties:6266-6372
> /branches/project-adptation-to-commons-1.1/src/main/resources/log4j.properties:1780-1790
> Properties on 
> '$REPO/trunk/project/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java':
>   svn:mergeinfo
> /branches/project-1.10/src/test/java/com/company/client/project/adherent/persistence/AdherentDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405
> /branches/project-1.13/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java:6266-6372
> /branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/adherent/persistence/AdherentDAOHibernateTest.java:1780-1790
> Properties on 
> '$REPO/trunk/project/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java':
>   svn:mergeinfo
> /branches/project-1.10/src/test/java/com/company/client/project/courrier/persistence/CourrierDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405
> /branches/project-1.13/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java:6266-6372
> /branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/courrier/persistence/CourrierDAOHibernateTest.java:1780-1790
> Properties on
> '$REPO/trunk/extranetof/src/main/filters/jse.filter.properties':
>   svn:mergeinfo
> Properties on '$REPO/trunk/project':
>   svn:mergeinfo
> /branches/project-1.10:2344-2345,2347,2349,2351,2361,2363,2405
> /branches/project-1.13:6266-6372
> /branches/project-adptation-to-commons-1.1:1780-1790
> Properties on 
> '$REPO/trunk/project/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java':
>   svn:mergeinfo
> /branches/project-1.10/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405
> /branches/project-1.13/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java:6266-6372
> /branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDAOHibernateTest.java:1780-1790
> Properties on 
> '$REPO/trunk/project/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java':
>   svn:mergeinfo
> /branches/project-1.10/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405
> /branches/project-1.13/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java:6266-6372
> /branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDAOHibernateTest.java:1780-1790
> 
> I leave as it is, it probably speaks to you more it does for me.

What strikes me is that you have a lot of subtree mergeinfo,
but no mergeinfo on the trunk root folder. This indicates that you
are probably not doing merges in a way you want to.

It looks as if changes were merged into files one-by-one, rather than
merging reivisions from the root of the source branch into the working
copy root. This happens e.g. if people right-click files in TortoiseSVN
to merge changes into them, or if they specify paths other than the
working copy root when using the svn merge command.
This works, but should only be done if you really need it.

Usually, you'd merge from one branch root to another.
Anything else is special, and if you're not a merging expert
and just want things to work, do not do it!
Right-click on the working copy root folder.
At the command line, change directory to your branch root before
doing merges, and use the default merge target path (which is ".",
the current directory).

Note that mergeinfo is always created at the merge target.
These are the locations of mergeinfo in trunk of your repository:

trunk
  project [svn:mergeinfo]
src
  test
resources
  log4j.properties [svn:mergeinfo]
java
  com
company
  client
project
  adherent
persistence
  AdherentDaoHibernateTest.java [svn:mergeinfo]
  courrier
persistence
  CourrierDaoHibernateTest.java [svn:mergeinfo]
  codeobjet
persistence
  CodeObjetDaoHibernateTest.java [svn:mergeinfo]
  dossierstagiaire
persistence
   

Re: Is there any way of extending the set of keywords recognized/expanded by Subversion?

[Ryan Schmidt]

On May 10, 2010, at 09:07, Edward Knoll wrote:

> Not Subversion source control, but some custom SCM/bookkeeping that has been 
> built around/on top of Subversion - layers application teams don't have 
> direct access.  My (forlorn) hope is there's a way of extending the keywords, 
> so the application team could reference these other bookkeeping artifacts as 
> embedded keywords and the process/SCM extensions could set those new keywords.

Sorry, there isn't any way of doing that, short of modifying the Subversion 
source code and using your own custom Subversion builds.

Re: Is there any way of extending the set of keywords recognized/expanded by Subversion?

[Erik Huelsmann]

Hi,

On Mon, May 10, 2010 at 7:33 PM, Ryan Schmidt
 wrote:
>
> On May 10, 2010, at 09:07, Edward Knoll wrote:
>
>> Not Subversion source control, but some custom SCM/bookkeeping that has been 
>> built around/on top of Subversion - layers application teams don't have 
>> direct access.  My (forlorn) hope is there's a way of extending the 
>> keywords, so the application team could reference these other bookkeeping 
>> artifacts as embedded keywords and the process/SCM extensions could set 
>> those new keywords.
>
> Sorry, there isn't any way of doing that, short of modifying the Subversion 
> source code and using your own custom Subversion builds.

Right. There's a patch (in our issue tracker) to support the same
thing for FreeBSD:
http://subversion.tigris.org/issues/show_bug.cgi?id=890

Bye,


Erik.

Re: Apache + SVN (+ LDAP) don't works

[Saulo Soares de Toledo]

Some more news! I changed a little and the error changed. I removed the
"DocumentRoot" from configuration too.

The new error is:
[Mon May 10 17:12:10 2010] [error] [client 192.168.254.241] client denied by
server configuration: /etc/apache2/htdocs



But /etc/apache2/htdocs does not exists, and I put "" and
"Allow from all" above. What is going wrong now?
And I'm not certainly if the another error will not happen





ServerAdmin m...@me.com
ServerName subversion.myserver

ErrorLog /var/log/apache2/subversion.myserver-error_log
CustomLog /var/log/apache2/subversion.myserver-access_log combined

LogLevel debug


DAV svn

SVNParentPath /home/files/svn_root
SVNListParentPath on

# Enable WebDAV automatic versioning
SVNAutoversioning On

# Repository Display Name
SVNReposName "Subversion Repository"

AuthType Basic
AuthName "(Subversion)"

AuthLDAPURL ldap://localhost/ou=Users,dc=my,dc=server,dc=net?uid
AuthLDAPBindDN cn=admin,dc=my,dc=server,dc=net
AuthLDAPBindPassword myPassword

AuthBasicProvider ldap
AuthUserFile /dev/null

Require valid-user



Order allow,deny
Allow from all



Order allow,deny
Allow from all





2010/5/10 Saulo Soares de Toledo 

> Hello all!
>
> I've tried this at IRC rooms without results, then I'm here to try the
> list! :)
>
> I'm trying enable Apache + LDAP + SVN to enable my SVN server service. All
> almost done, but with this config at Apache (I have this VH only to
> subversion!):
>
>
>1. 
>2.
>3. ServerAdmin m...@me.com
>4. ServerName subversion.myserver
>5.
>6. DocumentRoot /var/www/
>7.
>8. ErrorLog /var/log/apache2/subversion.myserver-error_log
>9. CustomLog /var/log/apache2/subversion.myserver-access_log
>combined
>10.
>11.
>12. 
>13. DAV svn
>14.
>15. SVNParentPath /home/files/svn_root
>16. SVNListParentPath on
>17.
>18. ## Enable WebDAV automatic versioning
>19. SVNAutoversioning On
>20.
>21. ## Repository Display Name
>22. SVNReposName "Subversion Repository"
>23.
>24. AuthType Basic
>25. AuthName "(Subversion)"
>26.
>27. AuthLDAPURL
>ldap://localhost/ou=Users,dc=my,dc=server,dc=net?uid
>28. AuthLDAPBindDN cn=admin,dc=my,dc=server,dc=net
>29. AuthLDAPBindPassword myPassword
>30.
>31. AuthBasicProvider ldap
>32. AuthUserFile /dev/null
>33.
>34. Require valid-user
>35.
>36. 
>37.
>38. 
>39. Order allow,deny
>40. Allow from all
>41. 
>42.
>43. 
>
>
>
> When I connect from a SVN client I receive
> the error "*Repository moved permanently to 'http:...'; please relocate*".
>
> The best info I found is here:
> http://subversion.apache.org/faq.html#http-301-error . With the content:
>
> *"It means your httpd.conf is misconfigured. Usually this error happens
> when you've defined the Subversion virtual "location" to exist within two
> different scopes at the same time.*
>
> *For example, if you've exported a repository as , but
> you've also set your DocumentRoot to be /www, then you're in trouble. When
> the request comes in for /www/foo/bar, apache doesn't know whether to find
> a **real file named /foo/bar within your DocumentRoot, or whether to ask
> mod_dav_svn to fetch a file /bar from the /www/foo repository. Usually the
> former case wins, and hence the "Moved Permanently" error.*
>
> *The solution is to make sure your repository  does not overlap
> or live within any areas already exported as normal web shares.*
>
> *It's also possible that you have an object in the web root which has the
> same name as your repository URL. For example, imagine your web server's
> document root is /var/www and your Subversion repository is located at
> /home/svn/repo. You then configure Apache to serve the repository at
> http://localhost/myrepo. If you then create the directory 
> /var/www/myrepo/this will cause a 301 error to occur."
> *
>
>
> But what's wrong with my config? I don't understood what is happening.
> My Apache logs have this (debug mode actived):
>
> [Fri May 07 18:14:19 2010] [error] [client 192.168.254.241] Could not fetch
> resource information.  [301, #0]
> [Fri May 07 18:14:19 2010] [error] [client 192.168.254.241] (2)No such file
> or directory: Requests for a collection must have a trailing slash on the
> URI.  [301, #0]
> [Fri May 07 18:22:28 2010] [error] [client 192.168.254.241] Could not fetch
> resource information.  

Apache + SVN (+ LDAP) don't works

[Saulo Soares de Toledo]

Hello all!

I've tried this at IRC rooms without results, then I'm here to try the list!
:)

I'm trying enable Apache + LDAP + SVN to enable my SVN server service. All
almost done, but with this config at Apache (I have this VH only to
subversion!):


   1. 
   2.
   3. ServerAdmin m...@me.com
   4. ServerName subversion.myserver
   5.
   6. DocumentRoot /var/www/
   7.
   8. ErrorLog /var/log/apache2/subversion.myserver-error_log
   9. CustomLog /var/log/apache2/subversion.myserver-access_log
   combined
   10.
   11.
   12. 
   13. DAV svn
   14.
   15. SVNParentPath /home/files/svn_root
   16. SVNListParentPath on
   17.
   18. ## Enable WebDAV automatic versioning
   19. SVNAutoversioning On
   20.
   21. ## Repository Display Name
   22. SVNReposName "Subversion Repository"
   23.
   24. AuthType Basic
   25. AuthName "(Subversion)"
   26.
   27. AuthLDAPURL
   ldap://localhost/ou=Users,dc=my,dc=server,dc=net?uid
   28. AuthLDAPBindDN cn=admin,dc=my,dc=server,dc=net
   29. AuthLDAPBindPassword myPassword
   30.
   31. AuthBasicProvider ldap
   32. AuthUserFile /dev/null
   33.
   34. Require valid-user
   35.
   36. 
   37.
   38. 
   39. Order allow,deny
   40. Allow from all
   41. 
   42.
   43. 



When I connect from a SVN client I receive the
error "*Repository moved permanently to 'http:...'; please relocate*".

The best info I found is here:
http://subversion.apache.org/faq.html#http-301-error . With the content:

*"It means your httpd.conf is misconfigured. Usually this error happens when
you've defined the Subversion virtual "location" to exist within two
different scopes at the same time.*

*For example, if you've exported a repository as , but
you've also set your DocumentRoot to be /www, then you're in trouble. When
the request comes in for /www/foo/bar, apache doesn't know whether to find a
**real file named /foo/bar within your DocumentRoot, or whether to ask
mod_dav_svn to fetch a file /bar from the /www/foo repository. Usually the
former case wins, and hence the "Moved Permanently" error.*

*The solution is to make sure your repository  does not overlap or
live within any areas already exported as normal web shares.*

*It's also possible that you have an object in the web root which has the
same name as your repository URL. For example, imagine your web server's
document root is /var/www and your Subversion repository is located at
/home/svn/repo. You then configure Apache to serve the repository at
http://localhost/myrepo. If you then create the directory
/var/www/myrepo/this will cause a 301 error to occur."
*


But what's wrong with my config? I don't understood what is happening.
My Apache logs have this (debug mode actived):

[Fri May 07 18:14:19 2010] [error] [client 192.168.254.241] Could not fetch
resource information.  [301, #0]
[Fri May 07 18:14:19 2010] [error] [client 192.168.254.241] (2)No such file
or directory: Requests for a collection must have a trailing slash on the
URI.  [301, #0]
[Fri May 07 18:22:28 2010] [error] [client 192.168.254.241] Could not fetch
resource information.  [301, #0]
[Fri May 07 18:22:28 2010] [error] [client 192.168.254.241] Requests for a
collection must have a trailing slash on the URI.  [301, #0]
[Fri May 07 18:22:28 2010] [error] [client 192.168.254.241] Could not fetch
resource information.  [301, #0]
[Fri May 07 18:22:28 2010] [error] [client 192.168.254.241] (2)No such file
or directory: Requests for a collection must have a trailing slash on the
URI.  [301, #0]
[Fri May 07 18:26:14 2010] [error] [client 192.168.254.241] Could not fetch
resource information.  [301, #0]
[Fri May 07 18:26:14 2010] [error] [client 192.168.254.241] Requests for a
collection must have a trailing slash on the URI.  [301, #0]
[Fri May 07 18:26:14 2010] [error] [client 192.168.254.241] Could not fetch
resource information.  [301, #0]
[Fri May 07 18:26:14 2010] [error] [client 192.168.254.241] (2)No such file
or directory: Requests for a collection must have a trailing slash on the
URI.  [301, #0]
[Fri May 07 18:34:15 2010] [debug] mod_deflate.c(615): [client
192.168.254.241] Zlib: Compressed 484 to 328 : URL /svn
[Fri May 07 18:34:19 2010] [debug] mod_authnz_ldap.c(379): [client
192.168.254.241] [26599] auth_ldap authenticate: using URL
ldap://localhost/ou=Users,dc=my,dc=server,dc=net?uid
[Fri May 07 18:34:19 2010] [debug] mod_authnz_ldap.c(484): [client
192.168.254.241] [26599] auth_ldap authenticate: accepting saulo
[Fri May 07 18:34:19 2010] [debug] mod_authnz_ldap.c(556): [client
192.168.254.241] [26599] auth_ldap authorise: declining to authorise (no
ldap requirements)
[Fri May 07 18:34:19

Complex Apache configuration: allow anonymous read access just from a specific IP

[Paulo Eduardo Neves]

Hi,
due to some strict business requirements, I need to do an overly
complex subversion repository access through Apache.  I won't
configure it myself, so please see this is a no exit alley. Maybe
there is even a simpler way to configure it.

I'm integrating two repositories using the svn:external property.

I'm thinking to configure this external repository with  two virtual
hosts. One open to everybody in the Internet, just can be accessed
with a password. The other one will just be accessed by my project,
will have a "host allow ip.of.my.proxy' and the option "Satisfy Any"

My great doubt is if two virtual hosts can access the same repository
without conflicts.

Is this a good idea?

Here are my  restrictions are:
1) I'd like to access the external repository for reading without
passwords
2) Just our proxy server my access the repository without password
3) We should be able to access just a subdir in the external
repository
4) the external repository should be password accessible for anybody
in the Internet
5) a few people here would access the external  repository with a
password to do commits

regards,
Paulo Eduardo Neves