Re: Obtaining log messages for a diff

[Nicolai Scheer]

Hi Mark,

On 19 May 2015 at 15:51, Mark Phippard  wrote:
> On Mon, May 18, 2015 at 8:59 AM, Nicolai Scheer 
> wrote:
>>
>> Hi all,
>>
>> we run our subversion repository with a rather standard layout, e.g.:
>>
>> /trunk
>> /branches/1.0.x
>> /branches/1.1.x
>> /tags/1.0.0
>> /tags/1.0.1
>> /tags/1.1.0
>> /tags/1.1.1
>>
>> Trunk of a project gets branched to the branches folder, and tagged from
>> there on.
>>
>> We enforce that every commit's message includes a ticket number for
>> reference.
>>
>> Currently, I'm trying to solve a seemingly simple task, that is, answer
>> the question:
>> "what's new in the release 1.0.1?".
>>
>
> Assuming you know the revisions tag in 1.0.0 and 1.0.1 can't you just run
> svn log on branches/1.0.x and ask for all changes between those two
> revisions?

Yes, that is the straighforward way. Unfortunately we "broke" this,
when we restructured our repository and had to move a lot of tags.
For newly created tags this works - but we needed a universal approach.

Greetings

Nico

Re: local dir edit, incoming dir delete upon update

[Stefan Sperling]

On Mon, Apr 06, 2015 at 08:54:20AM -0600, Warren Block wrote:
> May I humbly request improvements for this error message?
> 
>   local dir edit, incoming dir delete upon update
> 
> The ambiguity of "edit" and "delete" (whether adjectives or verbs) is
> confusing every time.
> 
> Could it be:
> 
>   local dir has been modified, but dir has been deleted in repository
> 
> Or something like that.
> 
> Thanks!

Hi Warren,

Are you simply asking for the wording to change? Or are you asking
for a more precise description of how the tree conflict came about?

The degree of ambiguity goes much further than one might expect.

Most tree conflict messages are very terse and usually fail to describe
the actual conflict situation in an adequate fashion. Currently it's up
to the user to figure out what really happened. The message provides a
small hint based on the information available to the client at the time
the conflict was recorded. More often than not it lacks sufficient detail.

'edit' was chosen to describe local changes that occurred somewhere at
or within a directory. These changes may be "local" to a branch (in case
of merge) or a working copy (in case of merge or update).
The client does not always know what the local changes are. E.g. in case
changes happened in the history of a branch it currently does not know
much about them, since conflict recording does not take history of the
merge target into account. Only the tree configuration resulting from
the local changes is known.

Perhaps 'modification' would be a better term than 'edit'. But I don't
see how such a small change in wording alone provides a huge improvement.

As I see it, the situation as a whole could be vastly improved by providing
more information to the client, or trying to make the client get at more
information, so the conflict can be described to the user in more detail.

FWIW, Subversion 1.9 describes your tree conflict as follows, hinting at
the possibility that the incoming delete could also be an incoming move
(perhaps causing more confusion for users, or perhaps not :-)

   > local dir edit, incoming dir delete or move upon update
  
I think that, ideally, SVN should show something like this (I'm making
up a conflict description and some possible resolution options -- there
could be other options users might want):

Tree conflict while merging r4242 from
  '^/trunk'
into
  '^/branches/5.4.x@5100'
with common ancestor '^/trunk@4180':
 'harry' removed directory '^/trunk/foo' in r4242
 'sally' edited '^/branches/5.4.x/foo/README.txt' in r5003 
 'bob' edited '^/branches/5.4.x/foo/src/common.c' in r5010
 'alice' edited svn:ignore on '^/branches/5.4.x/foo' in r5013
 More local changes present but not shown. To see all local changes, use:
   svn log -r 4180:4242 ^/branches/5.4.x/foo@5100
 Select: (p) postpone, (q) quit resolution, (h) help,
 (k) keep local directory 'foo' as-is
 (d) accept the deletion directory 'foo' discarding all local changes
 (m) move 'branches/5.4.x/foo' to a different path

Some of these improvements could already be made today. But we've been
waiting for advances in server-side move tracking before making additional
changes to the conflict menu and the underlying APIs which support it.

Server-side move tracking is being researched but there is no solution
ready to be part of a future release yet. Note how an incoming move would
affect our idealized conflict description and set of resolution options:

 'harry' moved directory '^/trunk/foo' to '^/trunk/bar' in r4242
 'sally' edited '^/branches/5.4.x/foo/README.txt' in r5003 
 'bob' edited '^/branches/5.4.x/foo/src/common.c' in r5010
 'alice' edited svn:ignore on '^/branches/5.4.x/foo' in r5013
 More local changes present but not shown. To see all local changes, run:
   svn log -r 4180:4242 ^/branches/5.4.x/foo@5100
 Select: (p) postpone, (q) quit resolution, (h) help,
 (k) keep local directory 'foo' as-is
 (m) rename local foo to bar and merge any outstanding differences
 between incoming bar and local bar

Compiling Subversion

[Chandra, Ramesh H.S. IN BLR STS]

Hello,



The OS is "Ubuntu 14.04 LTS Server".



I have download subversion-1.8.13 tar.gz package. After that, using 
the "alien" CLI, I converted the tar package to .deb package. I placed this 
.deb package under /var/cache/apt/archives and using dpkg -i <.deb package 
name> the package got installed under /subversion-1.8.13 directory. But the 
exes (svn, svnadmin) were not present.



I have gcc-4.9 compiler on this machine. BTW, I copied gcc-4.9 as 
"gcc".



I am trying to build the sources. When I execute ./configure from 
the subversion directory, it is giving me the following error:



root@INBLRKUN1001:/subversion-1.8.13# ./configure

configure: Configuring Subversion 1.8.13

configure: creating config.nice

checking for gcc... gcc

checking whether the C compiler works... no

configure: error: in `/subversion-1.8.13':

configure: error: C compiler cannot create executables

See `config.log' for more details

root@INBLRKUN1001:/subversion-1.8.13#



So, how do I build subversion and get all the executables?



NOTE : In our company, there is a policy that internet access will 
not be given to machines having Ubuntu OS. So, I cannot use "apt-get install 
" .



Please let me know how to proceed.



Thanks and Regards,
Ramesh Chandra

Re: Best version for RHEL7/CentOS 7?

[Les Mikesell]

On Tue, Apr 28, 2015 at 4:37 PM, Les Mikesell  wrote:
>
>>> Can someone comment on the best version of subversion to run on
>>> CentOS7?   The distribution supplies 1.7.14.I was thinking of
>>> using the packaged 1.8.x from Wandisco, but I don't see a mod_dav_svn
>>> here:
>>> http://opensource.wandisco.com/centos/7/svn-1.8/RPMS/x86_64/
>>> Does that mean there is a problem building it or am I missing something?
>>>
>
>> In general, the CentOS releases will be based on more regression
>> tested, stable source from RHEL. Even though I publish the tools to
>> build backport SRPM's and RPM's myself, at https://github.com/nkadel/,
>> I'd encourage stable, upstream tested tools where feasible. And I'd
>> jump to 1.7.20, or even to the noticeable performance and integration
>> of 1.8.13, only if I really need some of the new features.
>>
>> This is especially true of you have NFS or CIFS based home directories
>> and will access them with 1.8.x on one upgraded system and 1.7.x on
>> another system for the same working copy.
>

Looking into this a bit more, it appears that the mod_dav shipped in
RHEL/CentOS7 has a bug that breaks mod_dav_svn.  Has anyone worked
around this yet or am I the only person who wants to run a
newer-than-stock subversion with http access on RHEL/CentOS 7?

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

Re: Compiling Subversion

[Kris Deugau]

Chandra, Ramesh H.S. IN BLR STS wrote:

> I am trying to build the sources. When I execute ./configure
> from the subversion directory, it is giving me the following error:

> root@INBLRKUN1001:/subversion-1.8.13# ./configure
> configure: Configuring Subversion 1.8.13
> configure: creating config.nice
> checking for gcc... gcc
> checking whether the C compiler works... no

You do not have a complete software build environment.  Your compiler is
missing key pieces (or not installed at all).

> So, how do I build subversion and get all the executables?

> NOTE : In our company, there is a policy that internet
> access will not be given to machines having Ubuntu OS. So, I cannot use
> “apt-get install ” .

You're going to have to spend a long time working around this
restriction to download the many packages necessary to support building
a complex package like Subversion.  "apt-get build-essential" would
normally get you started, and that covers a bare minimum ~20+ packages
just for doing general package-building.  I just checked a recent Debian
(Ubuntu is mostly Debian, so the package dependencies are usually almost
identical), and Subversion's own build requirements add another 124
packages.  Also note that this was on a VM I periodically do custom PHP
builds on, so there are probably as many as 30 -dev packages that
overlap with the full set necessary for building Subversion, already
installed.

Or you're going to have to spend quite a bit less time working around
this restriction to download prebuild Subversion packages and the
handful of dependencies it needs to run.

-kgd

Re: SVN write through proxy out off sync

[Mustafa Karci]

Well, the problem seems to be the logg. In de svn i had enabled logg. So
the /var/log/http was around 7gb. This is makes no sence because we still
had more than 20gb of free disk space. So disabled log and removing all
files in the http,  this seems to do the job.

And the question do we monitoring. Is yes and we also running a script that
will watch the revision diferance between master and mirror. And do a sync
when the 2 are out off sync. Wel the script does more than that. Timeout
prefention. Delay to do a sync, and so on.

Op 15 mei 2015 19:22 schreef "Eric Johnson" :

> Looks to me like the sync failed at one point, and there's a pending lock
> on the mirror repository. Remove the lock and try the sync again.
>
> On Fri, May 15, 2015 at 3:10 AM, Mustafa Karci  wrote:
>
>> Today ore svn mirrror got out off sync. The setup is as the headline
>> describes. We have setup a mirror that does only read actions and write
>> actions are committed to the master SVN server.
>>
>> So on the mirror we have in the /etc/http/conf.d/mirror.conf file. this
>> has 2 locations created. The private branch that redirects all writes to
>> the master "SVNMasterURI" and a second Where the sync from master is send
>> to.
>>
>> And yes, all hook scrip are executable. So the problem is : Some in 6
>> mounts the mirror would got out off sync because the locking mechanism was
>> in please. So normally We would do a
>>
>> svn propdel --revprop -r0 svn:sync-lock http://mirror/svn-proxy-sync
>> svnsync sync http://mirror/svn-proxyn-sync file:///home/master/svn/private
>>
>> But now doing a svnsync sync http://mirror/svn-proxyn-sync 
>> file:///home/master/svn/private
>> we get an error messages like :
>>
>>  svnsync: DAV request failed; it's possible that the repository's pre-   
>> revprop-change hook either failed or is non-existent
>>  svnsync: At least one property change failed; repository is unchanged
>>  svnsync: Error setting property 'sync-lock':
>>  Can't find a temporary directory: Internal error
>>
>> here are the config file:
>>
>> master SVN
>>
>>  
>>   DAV svn
>>   SVNListParentPath Off
>>   SVNPath /home/master/svn/private
>>   #SVNParentPath /var/www/svn
>>   AuthType Basic
>>   AuthName "BLA BLA"
>>   AuthUserFile /home/master/svn/etc/htpasswd
>>   AuthzSVNAccessFile /home/master/svn/etc/private.access
>>   Require valid-user
>>  
>>
>> Mirror write through proxy
>>
>>  
>>DAV svn
>>SVNListParentPath Off
>>SVNPath /home/mirror/svn/private
>>SVNMasterURI http://svnmaster/svn/master
>>#SVNParentPath /var/www/svn
>>AuthType Basic
>>AuthName "BLA BLA BAL"
>>AuthUserFile /home/mirror/svn/etc/htpasswd
>>AuthzSVNAccessFile /home/mirror/svn/etc/private.access
>>Require valid-user
>>  
>> 
>>DAV svn
>>SVNListParentPath Off
>>SVNPath /home/mirror/svn/private
>>Order deny,allow
>>Deny from all
>>Allow from xxx.xxx.xxx.xxx
>>
>> Also when we tried to do a
>>
>> svnsync init commando we are getting the same output
>>
>>
>> --
>> Mustafa Karci
>>
>>
>> The IP Company
>> Kruisweg 609
>> 2132 NB  Hoofddorp
>> The Netherlands
>>
>> Website: www.theipcompany.nl
>> Phone number: 085 1119158
>> Direct phone number: 085 1119158
>>
>
>

Re: Obtaining log messages for a diff

[Daniel Shahaf]

Nicolai Scheer wrote on Wed, May 20, 2015 at 11:40:49 +0200:
> On 19 May 2015 at 15:51, Mark Phippard  wrote:
> > Assuming you know the revisions tag in 1.0.0 and 1.0.1 can't you just run
> > svn log on branches/1.0.x and ask for all changes between those two
> > revisions?
> 
> Yes, that is the straighforward way. Unfortunately we "broke" this,
> when we restructured our repository and had to move a lot of tags.
> For newly created tags this works - but we needed a universal approach.

You can use --stop-on-copy to determine not only the most recent copy,  
but also the one before that (and so on), using peg revisions.  You'd
just have to invoke svn multiple times iteratively until you hit the
right copy operation.

The history / location segments APIs should be able to answer this
question in one invocation, but I don't think they're exposed by the
cmdline client.

reintegrate merge failing because "can only be used if revisions were previously merged", but it's a lie (I think?)

[Charlet, Ricky]

Howdy,

I have a trunk and a feature branch. Time has come (it was long, over a 
year) to reintegrate back into trunk. I have subversion 1.8 on both server and 
client (though a year ago, we were using 1.6 server and client).

I have recently (like yesterday) merged trunk to branch successfully. 
It passes verification and sanity testing. I like the branch.

From within an up-to-date trunk working copy, if I attempt the merge 
branch back to trunk I get some complaints:
[charletr@ariesbld trunk]$ svn merge ^/6WINDGate/branches/DUAL_SSL_Inspection . 
--dry-run --accept postpone 
svn: E195016: Reintegrate can only be used if revisions 15725 through 26003 
were previously merged from 
https://csvnrose-pro.rose.hp.com:18180/svn/tpt-6wind/6WINDGate/trunk to the 
reintegrate source, but this is not the case:
  
6WINDGate/branches/DUAL_SSL_Inspection/ports/lsm/lsmclient/test/cukes/features/1_package_update
Missing ranges: 
/6WINDGate/trunk/ports/lsm/lsmclient/test/cukes/features/1_package_update:19595
  6WINDGate/branches/DUAL_SSL_Inspection/ports/xtrap/scripts
Missing ranges: /6WINDGate/trunk/ports/xtrap/scripts:21872
  
6WINDGate/branches/DUAL_SSL_Inspection/user/switch/sdk-xgs-robo-6.4.0/systems/linux/kernel/constellation-2_6
Missing ranges: 
/6WINDGate/trunk/user/switch/sdk-xgs-robo-6.4.0/systems/linux/kernel/constellation-2_6:17549,18282
  
6WINDGate/branches/DUAL_SSL_Inspection/user/switch/sdk-xgs-robo-6.4.0/systems/linux/user/constellation-2_6
Missing ranges: 
/6WINDGate/trunk/user/switch/sdk-xgs-robo-6.4.0/systems/linux/user/constellation-2_6:17549

[charletr@ariesbld trunk]$


Soo... that's a bit hard to believe because I did just recently merge 
trunk to branch. Furthermore, if I go into my branch working copy and attempt 
to merge an exact change (let me pick revision 19595 as an example because it's 
first in the listing above), nothing happens:
[charletr@ariesbld DUAL_SSL_Inspection]$ svn merge ^/6WINDGate/trunk . --accept 
postpone  -r 19595:19595
[charletr@ariesbld DUAL_SSL_Inspection]$ svn merge ^/6WINDGate/trunk . --accept 
postpone  -r 19594:19596
--- Recording mergeinfo for merge of r19595 through r19596 into '.':
 U   .
[charletr@ariesbld DUAL_SSL_Inspection]$ svn stat -q
[charletr@ariesbld DUAL_SSL_Inspection]$ svn ci
[charletr@ariesbld DUAL_SSL_Inspection]$


FYI, here is the view of mergeinfo from my trunk and branch:
[charletr@ariesbld trunk]$ svn propget svn:mergeinfo 
ports/lsm/lsmclient/test/cukes/features/1_package_update
[charletr@ariesbld trunk]$

[charletr@ariesbld DUAL_SSL_Inspection]$ svn propget svn:mergeinfo 
ports/lsm/lsmclient/test/cukes/features/1_package_update
/6WINDGate/branches/zorro_trunk_merge/ports/lsm/lsmclient/test/cukes/features/1_package_update:21398-23471
/6WINDGate/production/aries_1.1.1/ports/lsm/lsmclient/test/cukes/features/1_package_update:21842,21867,21906,22087,22270,22334
/6WINDGate/trunk/ports/lsm/lsmclient/test/cukes/features/1_package_update:15746-19001,19597-25912
[charletr@ariesbld DUAL_SSL_Inspection]$

Notice that 19595 is, infact, missing from branch's mergeinfo. 



In summary, A recent merge from trunk to branch suceeded, trunk cannot 
reintegrate because it claims that some change sets are not merged to branch, 
attempts to merge those exact change sets into branch produce a no-op, 
mergeinfo on branch confirms those change sets are missing.

I'm stuck... any ideas what to try next?


--
Ricky Charlet
Software Dev / Routing Dude: Aries team, Roseville CA
ricky.char...@hp.com
USA: 916.785.2090

Re: reintegrate merge failing because "can only be used if revisions were previously merged", but it's a lie (I think?)

[Andreas Stieger]

You may have explicit subtree merge tracking information which differs from 
that on what is normally the root of the working copy and merge operation. 
These accumulate on actual merges on subtrees as well as copy operations to 
resolve tree conflicts. While it is a valid use case it is more likely to cause 
issues.

To diagnose:
svn propget -R svn:mergeinfo

To remove explicit subtree merge tracking information:
svn propdel -R svn:mergeinfo
svn revert . 

Andreas

Am 21.05.2015 02:51 schrieb "Charlet, Ricky" :
>
> Howdy, 
>
> I have a trunk and a feature branch. Time has come (it was long, over a year) 
> to reintegrate back into trunk. I have subversion 1.8 on both server and 
> client (though a year ago, we were using 1.6 server and client). 
>
> I have recently (like yesterday) merged trunk to branch successfully. It 
> passes verification and sanity testing. I like the branch. 
>
> From within an up-to-date trunk working copy, if I attempt the merge branch 
> back to trunk I get some complaints: 
> [charletr@ariesbld trunk]$ svn merge ^/6WINDGate/branches/DUAL_SSL_Inspection 
> . --dry-run --accept postpone 
> svn: E195016: Reintegrate can only be used if revisions 15725 through 26003 
> were previously merged from 
> https://csvnrose-pro.rose.hp.com:18180/svn/tpt-6wind/6WINDGate/trunk to the 
> reintegrate source, but this is not the case: 
>   
> 6WINDGate/branches/DUAL_SSL_Inspection/ports/lsm/lsmclient/test/cukes/features/1_package_update
>  
>     Missing ranges: 
> /6WINDGate/trunk/ports/lsm/lsmclient/test/cukes/features/1_package_update:19595
>  
>   6WINDGate/branches/DUAL_SSL_Inspection/ports/xtrap/scripts 
>     Missing ranges: /6WINDGate/trunk/ports/xtrap/scripts:21872 
>   
> 6WINDGate/branches/DUAL_SSL_Inspection/user/switch/sdk-xgs-robo-6.4.0/systems/linux/kernel/constellation-2_6
>  
>     Missing ranges: 
> /6WINDGate/trunk/user/switch/sdk-xgs-robo-6.4.0/systems/linux/kernel/constellation-2_6:17549,18282
>  
>   
> 6WINDGate/branches/DUAL_SSL_Inspection/user/switch/sdk-xgs-robo-6.4.0/systems/linux/user/constellation-2_6
>  
>     Missing ranges: 
> /6WINDGate/trunk/user/switch/sdk-xgs-robo-6.4.0/systems/linux/user/constellation-2_6:17549
>  
>
> [charletr@ariesbld trunk]$ 
>
>
> Soo... that's a bit hard to believe because I did just recently merge trunk 
> to branch. Furthermore, if I go into my branch working copy and attempt to 
> merge an exact change (let me pick revision 19595 as an example because it's 
> first in the listing above), nothing happens: 
> [charletr@ariesbld DUAL_SSL_Inspection]$ svn merge ^/6WINDGate/trunk . 
> --accept postpone  -r 19595:19595 
> [charletr@ariesbld DUAL_SSL_Inspection]$ svn merge ^/6WINDGate/trunk . 
> --accept postpone  -r 19594:19596 
> --- Recording mergeinfo for merge of r19595 through r19596 into '.': 
> U   . 
> [charletr@ariesbld DUAL_SSL_Inspection]$ svn stat -q 
> [charletr@ariesbld DUAL_SSL_Inspection]$ svn ci 
> [charletr@ariesbld DUAL_SSL_Inspection]$ 
>
>
> FYI, here is the view of mergeinfo from my trunk and branch: 
> [charletr@ariesbld trunk]$ svn propget svn:mergeinfo 
> ports/lsm/lsmclient/test/cukes/features/1_package_update 
> [charletr@ariesbld trunk]$ 
>
> [charletr@ariesbld DUAL_SSL_Inspection]$ svn propget svn:mergeinfo 
> ports/lsm/lsmclient/test/cukes/features/1_package_update 
> /6WINDGate/branches/zorro_trunk_merge/ports/lsm/lsmclient/test/cukes/features/1_package_update:21398-23471
>  
> /6WINDGate/production/aries_1.1.1/ports/lsm/lsmclient/test/cukes/features/1_package_update:21842,21867,21906,22087,22270,22334
>  
> /6WINDGate/trunk/ports/lsm/lsmclient/test/cukes/features/1_package_update:15746-19001,19597-25912
>  
> [charletr@ariesbld DUAL_SSL_Inspection]$ 
>
> Notice that 19595 is, infact, missing from branch's mergeinfo. 
>
>
>
> In summary, A recent merge from trunk to branch suceeded, trunk cannot 
> reintegrate because it claims that some change sets are not merged to branch, 
> attempts to merge those exact change sets into branch produce a no-op, 
> mergeinfo on branch confirms those change sets are missing. 
>
> I'm stuck... any ideas what to try next? 
>
>
> -- 
> Ricky Charlet 
> Software Dev / Routing Dude: Aries team, Roseville CA 
> ricky.char...@hp.com 
> USA: 916.785.2090 
>

Re: Best version for RHEL7/CentOS 7?

[Eliop]

Les, I´ve installad Collabnet Subversion Edge 4.0.13 over CentOS 7 (miminal
ISO) and works fine.