svn:externals to another svn:externals issue

[Andrew]

Hello all!

I've got an issue with a repo that I manage regarding svn:externals
and have been unable to find any information regarding it (apologies
if the issue has already been brought up and I didn't find it.)

So I've got a pair of projects, we'll call them /tools and /libs.
Under each I'm using ./tags/v1.0 ./tags/v2.0 as well as an
svn:externals of ./tags/latest which points to the most recent tagged
version.  This all works fine.  What I'd like to do and seem to be
unable is to use svn:externals to point from /tools/tags/v2.0/libs to
/libs/tags/latest, as that directory only exists as a property of it's
parent.  I'd like to use this so that I don't have to worry about
updating the libs path for my tools every time I release a new
version.

Does anyone have any ideas on how I might be able to accomplish this
or a more effective way of managing this code?

Thanks!

-- 
Andrew
http://blog.psych0tik.net

Implementing lightweight client over http. Where to start?

[Andrew Roughan]

Porting the full svn client to my environment is not something I am willing
to undertake myself.
So as an alternative I wanted to implement some Quick & Dirty interface over
HTTP hopefully with a cleartext password.
Is there a document that describes the http interfaces to svn server for
each function?

Thanks,
Andrew

Re: Implementing lightweight client over http. Where to start?

[Andrew Roughan]

On Mon, Oct 18, 2010 at 12:56 PM, Ryan Schmidt <
subversion-20...@ryandesign.com> wrote:

>
> What is this mysterious environment you have where Subversion does not
> already run?
>

Apple IIgs with a 1Mz 65816 processor (or faster with accelerators and
emulators).
Yes there is a C compiler, but abysmal performance is likely to be an issue.

On Mon, Oct 18, 2010 at 2:51 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> That depends on what you want that client to do


I don't intend to fully implement all functionality. I want to be able to
checkout and commit.

I will look into WebDav support a bit more. I've read a few more webdav
notes and found the references to RFCs.

Thanks,
Andrew

Merge Failing

[SUMNER Andrew]

Sorry if anyone gets this twice - I originally mailed to users at
subversion dot tigris dot org on the advice of somebody, but when I
actually went to the site it suggested this mailing list.

 

I am attempting to merge the project trunk into a branch but after
nearly 10 minutes it fails with the error message:

 

Runtime Error!

Program C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe

This application has requested the Runtime to terminate in an unusual
way.

 

I have also had at times some errors about running out of memory and the
Task Manager backs this up as I can see the memory usage climbing and
the computer grinds to a crawl until the merge crashes.

 

I have now tried:

1.  Merging using TortoiseSVN windows interface 

2.  Merging via command line using both VisualSVN
and SilkSVN.  All fail with the same error - out of memory.  This would
indicate to me that there is a problem with svn itself.  

3.  Merging a single revision to attempt to minimize
the number of changes but it still fails.

4.  Merging a single folder containing less than 100
items - it worked!  Problem is that I have 150 or so folders and around
5,000 objects so I can't manually merge each one.

 

Thanks in advance

  Andrew

 

Version Information

Window XP Professional SP3

Visual SVN Server running on Windows Server 2003 SP2

 

TortoiseSVN 1.6.12, Build 20536 - 32 Bit , 2010/11/24 20:59:01

Subversion 1.6.15, 

apr 1.3.8

apr-utils 1.3.9

neon 0.29.5

OpenSSL 0.9.8p 16 Nov 2010

zlib 1.2.3

 

 

 


The information contained in this e-mail may be privileged and/or sensitive. It 
is intended for the addressee only and is not necessarily the official view or 
communication of the New Zealand Customs Service. If you are not the intended 
recipient you are asked to not disclose, copy, or make use of its contents. If 
received in error you are asked to destroy this e-mail and contact the sender 
immediately. Your assistance is appreciated.

RE: SVN Subversion- object level checkout

[SUMNER Andrew]

As Mark has already stated, you need to use PushOk's SVN plugin to
achieve this and you need to check in/out within PowerBuilder.

I have just completed an evaluation of source control tools and SVN
using PushOk SVN plugin combination was the only one I found that worked
well with PowerBuilder 11.5.

There are other plugins available but PushOKs was by far the best.

Mark also mentioned that version 12 gets rid the horror that is the PBL.
Unfortunately that is only in the Visual Studio version and I'm not sure
I want to go down that path in its first release.  The classic version
still uses PBLs.

Cheers
  Andrew

-Original Message-
From: amit.sas...@wipro.com [mailto:amit.sas...@wipro.com] 
Sent: Thursday, 13 January 2011 20:25
To: mdi...@elego.de
Cc: users@subversion.apache.org; sudip.da...@wipro.com;
pabitra.mall...@wipro.com; avik.na...@wipro.com; sourav.s...@wipro.com
Subject: RE: SVN Subversion- object level checkout

Hello Micheal,

Thanks for your mail.

We are using Tortoise SVN-1.6.7 alongwith Power Builder 11.5. 

We want to lock (check-out) the core power builder object from SVN so
that only one user can modify the object for that time. For this case,
If we want to open the workspace from the repository (SVN) we are
getting the attached message.

Please let us know the correct process for the Power Builder connectivty
with the proper Tortoise SVN SCC version to lock the core PB object. 

Appreciate your quick help.

Regards,

Amit Sasmal.
Wipro Technologies.


-Original Message-
From: Michael Diers [mailto:mdi...@elego.de] 
Sent: Wednesday, January 12, 2011 7:27 PM
To: SOURAV ROY (WT01 - Manufacturing)
Cc: users@subversion.apache.org; Sudip Datta (WT01 - Manufacturing);
Pabitra Mallick (WT01 - Manufacturing); Avik Nandi (WT01 -
Manufacturing); Amit Sasmal (WT01 - Manufacturing)
Subject: Re: SVN Subversion- object level checkout

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-01-12 09:57, sourav.s...@wipro.com wrote:
[...]
> We will use Tortoise SVN (Subversion) as version control system or SCM

> tool for our project. We are facing an issue for which we would like 
> to get a solution.
>  
> We are linking SVN to Powerbuilder 11.5. We are trying to checkout 
> files at object level. Every .pbl file, have many files inside. But 
> SVN is not able to checkout those individual files which are inside
the pbl file.
> So is there a way by which SVN can checkout those files which are 
> inside pbl.
>  
> TortoiseSVN 1.6.7,  2010/01/22
> Subversion 1.6.9
[...]

Sourav,

you need to play by PowerBuilder's rules, I'm afraid. Trying to use
TortoiseSVN or any other "plain" Subversion client for checkin/checkout
will cause you grief.

You can still use TortoiseSVN for other tasks, like browsing logs,
tagging and branching.

The IDE supports the SCC API, and you need to use a plug-in for the IDE
that can drive Subversion via SCC. This will magically do the right
thing with objects in PBLs. Note that SCC encourages a serialized
workflow with reservation ("locking") of objects.

We evaluated PushOK's product a couple of years ago; at the time, it
proved a good fit for our customer's needs.

http://stackoverflow.com/questions/1162141/is-there-a-viable-scc-integra
tion-for-subversion

(Please upgrade to Subversion 1.6.15. Subversion 1.6.9 sports a number
of bugs that have been fixed since its release.)

- --
Michael Diers, elego Software Solutions GmbH, http://www.elego.de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0ts0EACgkQcEKlWnqVgz0QngCfcTZ5gHe8upwsAH5x3zNZbFXB
6vEAn27V2eskpxWfOfh5Hyu6747LFZlg
=jf++
-END PGP SIGNATURE-

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain proprietary, confidential or privileged information. If
you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email. 

www.wipro.com
The information contained in this e-mail may be privileged and/or sensitive. It 
is intended for the addressee only and is not necessarily the official view or 
communication of the New Zealand Customs Service. If you are not the intended 
recipient you are asked to not disclose, copy, or make use of its contents. If 
received in error you are asked to destroy this e-mail and contact the sender 
immediately. Your assistance is appreciated.

RE: Merge Failing

[SUMNER Andrew]

I tried version 1.6.12 and 1.6.13 but got the same thing.  Looking at Windows 
Task Manager I can see the Page File Usage gradually building until the crash 
occurs.

The command I am using is:
"C:\program files\sliksvn\bin\svn.exe" merge 
https://xxx.xxx.xxx.xxx:000/svn/PowerBuilder/CusMod/trunk

Where do I find the crash dump/log file?

Windows Event Log:
==
Event Type: Error
Event Source:   Application Error
Event Category: None
Event ID:   1000
Date:   14/01/2011
Time:   9:31:21
User:   N/A
Computer:   WHOS786
Description:
Faulting application svn.exe, version 1.6.12.38263, faulting module 
sliksvn-libapr-1.dll, version 1.3.12.0, fault address 0x6b66.


-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com] 
Sent: Thursday, 13 January 2011 23:10
To: SUMNER Andrew
Cc: users@subversion.apache.org
Subject: Re: Merge Failing

On Wed, Jan 12, 2011 at 9:22 PM, SUMNER Andrew
 wrote:
> Sorry if anyone gets this twice - I originally mailed to users at subversion
> dot tigris dot org on the advice of somebody, but when I actually went to
> the site it suggested this mailing list.
>
>
>
> I am attempting to merge the project trunk into a branch but after nearly 10
> minutes it fails with the error message:
>
>
>
> Runtime Error!
>
> Program C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe
>
> This application has requested the Runtime to terminate in an unusual way.
>
>
>
> I have also had at times some errors about running out of memory and the
> Task Manager backs this up as I can see the memory usage climbing and the
> computer grinds to a crawl until the merge crashes.
>
>
>
> I have now tried:
>
> 1.  Merging using TortoiseSVN windows interface
>
> 2.  Merging via command line using both VisualSVN and
> SilkSVN.  All fail with the same error - out of memory.  This would indicate
> to me that there is a problem with svn itself.
>
> 3.  Merging a single revision to attempt to minimize the
> number of changes but it still fails.
>
> 4.  Merging a single folder containing less than 100
> items - it worked!  Problem is that I have 150 or so folders and around
> 5,000 objects so I can't manually merge each one.
>
>
>
> Thanks in advance
>
>   Andrew
>
>
>
> Version Information
>
> Window XP Professional SP3
>
> Visual SVN Server running on Windows Server 2003 SP2
>
>
>
> TortoiseSVN 1.6.12, Build 20536 - 32 Bit , 2010/11/24 20:59:01
>
> Subversion 1.6.15,
>
> apr 1.3.8
>
> apr-utils 1.3.9
>
> neon 0.29.5
>
> OpenSSL 0.9.8p 16 Nov 2010
>
> zlib 1.2.3

Just before yours, there was another report of a crash during merge
(with --reintegrate, but perhaps that's unrelated):
http://svn.haxx.se/users/archive-2011-01/0226.shtml.

That user reported that it worked with an older version of the client
(in his case, it worked with 1.6.12). Can you try with an older client
as well (try 1.6.13 perhaps, that's the release just before 1.6.15
(1.6.14 was never released)).

If that works, that could be a good workaround for you, and very
useful information for the developers as to where to look ...

Other useful information to help investigate the problem:
- The crash dump/log file.
- The exact commands you used when reproducing this from the command
line (feel free to obfuscate names/paths/files).

Thanks,
-- 
Johan
The information contained in this e-mail may be privileged and/or sensitive. It 
is intended for the addressee only and is not necessarily the official view or 
communication of the New Zealand Customs Service. If you are not the intended 
recipient you are asked to not disclose, copy, or make use of its contents. If 
received in error you are asked to destroy this e-mail and contact the sender 
immediately. Your assistance is appreciated.

RE: Merge Failing

[SUMNER Andrew]

Solved!

It turned out to be the way I created the branch.  I had taken a copy of
the trunk folder in windows explorer and in the copy done a branch and
switch.  It was in this copy that that merge was failing.

I created a brand new folder and did a svn checkout on the branch.
Merge worked beautifully after that.

Thanks
  Andrew


The information contained in this e-mail may be privileged and/or sensitive. It 
is intended for the addressee only and is not necessarily the official view or 
communication of the New Zealand Customs Service. If you are not the intended 
recipient you are asked to not disclose, copy, or make use of its contents. If 
received in error you are asked to destroy this e-mail and contact the sender 
immediately. Your assistance is appreciated.

can't delete svn:sync-lock

[Andrew Sasak]

using svn 1.6.13
When I attempt to delete it, it gives me a message indicating success,
however the property persists. Any ideas how to remove this? Can I safely
edit the revprops 0 file?

Re: can't delete svn:sync-lock

[Andrew Sasak]

svn propdel svn:sync-lock --revprop -r 0 REPO_URL

On Thu, Jan 27, 2011 at 4:18 PM, Stefan Sperling  wrote:

> On Thu, Jan 27, 2011 at 03:59:10PM -0500, Andrew Sasak wrote:
> > using svn 1.6.13
> > When I attempt to delete it, it gives me a message indicating success,
> > however the property persists. Any ideas how to remove this? Can I safely
> > edit the revprops 0 file?
>
> What command were you using?
>
> svn:sync-lock is a revision property.
> Did you pass the --revprop option to svn propdel?
>

Re: can't delete svn:sync-lock

[Andrew Sasak]

It was a hook preventing the deletion, not sure why I got a success message.
Thanks

On Thu, Jan 27, 2011 at 4:28 PM, Stefan Sperling  wrote:

> On Thu, Jan 27, 2011 at 04:22:30PM -0500, Andrew Sasak wrote:
> > svn propdel svn:sync-lock --revprop -r 0 REPO_URL
>
> That looks good.
>
> Maybe there is pre-revprop-change hook the prevents the prop from
> being deleted?
>
> It works here with a pre-revprop-change hook that simply does "exit 0".
>
> I'm not sure why you are seeing a message that indicates sucess
> even though deletion fails...
>
> In a working copy from the test repository:
>
> $ svn ps --revprop -r0 svn:svnsync-lock '*' ^/
> property 'svn:svnsync-lock' set on repository revision 0
> $ svn pl --revprop -v -r0 ^/
> Unversioned properties on revision 0:
>  svn:svnsync-lock
>*
>  svn:date
>2011-01-27T20:55:31.311289Z
> $ svn pd --revprop -r0 svn:svnsync-lock ^/
> property 'svn:svnsync-lock' deleted from repository revision 0
> $ svn pl --revprop -v -r0 ^/
> Unversioned properties on revision 0:
>  svn:date
>2011-01-27T20:55:31.311289Z
> $
>

Sync SVN to CVS

[SUMNER Andrew]

1.   Are there any tools to sync SVN to CVS?  Ideally I would like
two way sync but I may be able to get away with one way (svn -> cvs)
especially if it can throw an error if the cvs file has changed.

 

2.   How do I import CVS repository (including history) to SVN?

 

I am using Visual SVN (on windows server 2003) if this makes any
difference to tool selection.

 

The repository I wish to sync contains database script files.

 

Thanks

  Andrew


The information contained in this e-mail may be privileged and/or sensitive. It 
is intended for the addressee only and is not necessarily the official view or 
communication of the New Zealand Customs Service. If you are not the intended 
recipient you are asked to not disclose, copy, or make use of its contents. If 
received in error you are asked to destroy this e-mail and contact the sender 
immediately. Your assistance is appreciated.

RE: Sync SVN to CVS

[SUMNER Andrew]

Our operations group require that the database scripts are in cvs, however the 
developers are using svn for everything else and it would prefer to be using 
the one tool.  

My eventual goal being continuous deployment into test using Jenkins (also 
would love to hear from anyone who has done this for database changes...)

Andrew

-Original Message-
From: Thorsten Schöning [mailto:tschoen...@am-soft.de] 
Sent: Wednesday, 30 March 2011 20:34
To: users@subversion.apache.org
Subject: Re: Sync SVN to CVS

Guten Tag SUMNER Andrew,
am Dienstag, 29. März 2011 um 21:56 schrieben Sie:

> 1.   Are there any tools to sync SVN to CVS?  Ideally I would like
> two way sync but I may be able to get away with one way (svn -> cvs)
> especially if it can throw an error if the cvs file has changed.
[...]
> The repository I wish to sync contains database script files.

And what's the purpose you need the sync for or what problem do you
need to solve? It's unlikely that you find a tool which syncs as you
need, but maybe one has another idea on how to solve your problem.

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

The information contained in this e-mail may be privileged and/or sensitive. It 
is intended for the addressee only and is not necessarily the official view or 
communication of the New Zealand Customs Service. If you are not the intended 
recipient you are asked to not disclose, copy, or make use of its contents. If 
received in error you are asked to destroy this e-mail and contact the sender 
immediately. Your assistance is appreciated.

RE: Build project in pre-commit

[SUMNER Andrew]

I totally agree.  I have just started using it for a PowerBuilder
project and it has worked very well.

-Original Message-
From: David Weintraub [mailto:qazw...@gmail.com] 
Sent: Wednesday, 6 April 2011 11:05
To: San Martino
Cc: users@subversion.apache.org
Subject: Re: Build project in pre-commit

On Tue, Apr 5, 2011 at 6:08 PM, San Martino  wrote:
> we absolutely need to validate a project in the pre-commit trigger
> with a build of the whole project being committed.
>
> Is this possible? Are there any tools allowing this?

You can't really do it with a pre-commit script since the changes
aren't part of the repository. (well, you can but it's a lot of work).

The big problem is that your developers are sitting there twiddling
their thumbs staring at a blank screen and unable to do any work while
your application builds. Even a fast build takes a couple of minutes
to complete.

Your developers will hate Subversion, hate you, and hate their job.
Well, they actually already may hate Subversion, you and their job,
but this will make it even worse.

May I recommend something like Jenkins? (http://jenkins-ci.org).
Jenkins is a continuous build system that will do the build right
after the developer does a commit. On a bad build, Jenkins can then
mail the build results to the developer who did the commit and to the
development team responsible for the project.

Jenkins has a ton of plugins and can run unit tests, do deployments,
run code check styles, coverage reports, you name it. It integrates
with over 2 dozen defect tracking systems including Jira, and
integrates with web-based version control browsers like Sventon,
Fisheye, and ViewVC.

Jenkins is webbased, but doesn't need Apache to run. It comes with its
own application server built into the warfile. All you need is a JRE,
and the Windows MSI file comes with that.


-- 
David Weintraub
qazw...@gmail.com
The information contained in this e-mail may be privileged and/or sensitive. It 
is intended for the addressee only and is not necessarily the official view or 
communication of the New Zealand Customs Service. If you are not the intended 
recipient you are asked to not disclose, copy, or make use of its contents. If 
received in error you are asked to destroy this e-mail and contact the sender 
immediately. Your assistance is appreciated.

BUG Tree conflict + revert leads to missing/forgotten file

[Andrew Buchanan]

Hello all,
I just got bitten by what looks like a bug in the handling of tree conflicts
involving replaced files.  To demonstrate:
User A replaces foo.txt and commits their change:
$ svn st -v
R44 abuchananfoo.txt
$ svn commit -m 'replacing foo'
Replacing  foo.txt

User B has modified foo.txt and gets a tree conflict when they svn up:
$ svn up
   C foo.txt
At revision 5.
Summary of conflicts:
  Tree conflicts: 1
$ svn st -v
A  +  C  -4 abuchananfoo.txt
  >   local edit, incoming delete upon update

Knowing that their modifications can be discarded, user B tries to get
things on track by reverting foo.txt.
***This results in their local foo.txt no longer being versioned and their
working directory "forgetting" about the incoming replacement.***
$ svn revert foo.txt
Reverted 'foo.txt'
$ svn st -v
 55 abuchanan.
?foo.txt
$ svn up
At revision 5.
$ svn st -v
 55 abuchanan.
?foo.txt
$

foo.txt is in the repository, but svn up doesn't grab it.  Deleting the now
unversioned copy and running svn up with foo.txt as the explicit target will
correctly check it out, but it can be hard to realize that something's
missing when svn st and svn up of that directory say that everything's up to
date.

Thanks,
-Andrew

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.
> 

svnsync error - serialized hash missing terminator

[Andrew Sasak]

I have a mirror that is synced using svnsync from the master server.
The master server was updated to 1.7.1 yesterday, the mirror was updated to
1.7 last week.
I had a few good syncs occur yesterday after the master was updated.
The mirror locked up last night and was rebooted this morning.
Since then, I get the following error when svnsync is attempted:

svnsync: E175002: DAV request failed; it's possible that the repository's
pre-revprop-change hook either failed or is non-existent
svnsync: E175008: At least one property change failed; repository is
unchanged
svnsync: E175002: Error setting property 'sync-lock':
Serialized hash missing terminator



(Both mirror and master are running on Windows)

Re: svnsync error - serialized hash missing terminator

[Andrew Sasak]

I have no idea how the lockup occurred
I got no output when I ran propget
I got no output when I ran proplist
I attempted to delete the property anyway, it indicated success, but I still
get the same error.
Am I going to have to rebuild the mirror?
(Thanks for the response)

On Wed, Oct 26, 2011 at 1:22 PM, Stefan Sperling  wrote:

> On Wed, Oct 26, 2011 at 01:13:38PM -0400, Andrew Sasak wrote:
> > I have a mirror that is synced using svnsync from the master server.
> > The master server was updated to 1.7.1 yesterday, the mirror was updated
> to
> > 1.7 last week.
> > I had a few good syncs occur yesterday after the master was updated.
> > The mirror locked up last night and was rebooted this morning.
> > Since then, I get the following error when svnsync is attempted:
> >
> > svnsync: E175002: DAV request failed; it's possible that the repository's
> > pre-revprop-change hook either failed or is non-existent
> > svnsync: E175008: At least one property change failed; repository is
> > unchanged
> > svnsync: E175002: Error setting property 'sync-lock':
> > Serialized hash missing terminator
>
> Is there an existing svn:sync-lock property on revision zero of the
> slave's repository? If so, what does it look like?
> svn propget --revprop -r0 svn:sync-lock URL_TO_REPOS
>
> It sounds asif the problem is with parsing the existing property,
> which must be done since the lock needs to be checked.
>
> How did the lock-up you mentioned happen? Is it possible that the property
> got corrupted during the lock-up? For instance, because the file
> containing the serialized lock data was not fully written to disk by
> the operating system?
>
> In any case, if the property still exists and no sync job is running
> you need to remove it because it will prevent new sync jobs.
> Any svnsync process will believe that another svnsync process is currently
> writing to the repository.
>

dump/load question

[Andrew Sasak]

I maintain a mirror of a repository that I must sneakernet sync using
a "dump, burn cd, load" process. I use --deltas and --incremental to
dump. I do not have access to every directory in the repository.
Occasionally, I am given access to a directory after it has existed
for some time. The revision that the directory was created in was an
empty revision as a result of my permissions. When I attempt to load a
revision that modifies a file in this directory, the load fails, since
the changed files don't exist in the mirror. I'm wondering if there is
an easy to way to bring my mirror back into sync? A dumpfilter could
let me bring it nearly into sync by excluding the directory in
question. Would dumping a revision from the repository without the
incremental option and loading it to the mirror create the missing
directory and files?

svnrdump fails when access control restrictions are in place

[Andrew Sasak]

svnrdump fails when access control restrictions are in place on the
server and the --incremental option is not used. The message returned
is "authorization failed". This does not occur when the --incremental
option occurs. The svnrdump command is version 1.7.2.

Re: svnrdump fails when access control restrictions are in place

[Andrew Sasak]

When --incremental is used, dump records all changes that the user has
access to. When --incremental is used, I think dump should dump the
whole tree that the user has access to. I can imagine that this would
be a non-trivial change for an uncommon use case.

On Fri, Apr 13, 2012 at 1:25 PM, Daniel Shahaf  wrote:
> When --incremental isn't used svnrdump tries to dump the full tree and
> runs into the authz restrictions.  Do you have a suggestion for an
> alternative behaviour?
>
> Andrew Sasak wrote on Fri, Apr 13, 2012 at 11:58:50 -0400:
>> svnrdump fails when access control restrictions are in place on the
>> server and the --incremental option is not used. The message returned
>> is "authorization failed". This does not occur when the --incremental
>> option occurs. The svnrdump command is version 1.7.2.

RE: SVN keeps getting my AD password revoked.

[REEDICK, ANDREW]

Check for svn:externals that point to an external repository.  That password 
prompt may be for the external repository, and you're getting locked out (of 
the external repo) because you are providing the wrong password for the wrong 
repo.


From: Wendell Nichols [mailto:wc...@shaw.ca]
Sent: Tuesday, September 18, 2012 9:02 AM
To: Mark Phippard
Cc: Ryan Schmidt; users@subversion.apache.org
Subject: Re: SVN keeps getting my AD password revoked.

I cannot quite figure out how but the Eclipse SVN plugin is locking me out of 
AD even when it doesn't have invalid credentials.   I notice that I am working 
along doing many compares and merges and all of a sudden it asks me for my AD 
password.  At that point I'm locked out.  Eclipse is the only thing that could 
be responsible because every thing else runs 24/7 and has no problems.
I'll update it to see if it improves...
wcn
On 09/18/2012 06:53 AM, Mark Phippard wrote:
On Tue, Sep 18, 2012 at 8:47 AM, Wendell Nichols 
mailto:wc...@shaw.ca>> wrote:
Ok, from your description of the way the library behaves there is no retry 
logic in it for Auth failures, and this must be happening in the subversion 
connector for Eclipse.  I'll go complain to them :)
Thankyou for your analysis and have a good day!

This is why in Subclipse we do not cache your password in any way and leave it 
up to the Subversion library.  The way it should work is that SVN library will 
read its cache and try to use those credentials.  When they do not work it will 
fire callback API  that will cause you to get prompted for new credentials.  
Ideally (and I am not sure this true) the Subversion library should clear its 
cached credentials once they are invalid.  If it does not do this, and you have 
many projects in Eclipse, then I could see it still being possible to disable 
your password as each SVN API call for each of those projects might cause this 
sequence to happen.  That said, the calls are all happening in one thread so I 
would expect the first one to cause you to have to enter new credentials.

I think the other Eclipse plugin, Subversive, allows you to type your 
credentials into its UI and save them.  In which case, it could be causing this 
to happen.  I think, but am not sure, if you do not enter any credentials in 
their UI, then they allow the SVN library to manage this which might solve the 
problem.

--
Thanks

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

Re: WC database corruption (1.7.1)

[Andrew Robinson]

I know this is an old thread, but I see this error quite often with SVN 
1.7. I am using Cornerstone 2.7.7 which uses SVN 1.7.5 internally. I get 
corrupted working copies about once a month which of course ruins the 
working copy and is very difficult to recover from in terms of wasted time. 
I never had issues like this with SVN 1.6 and earlier. Not sure if it is 
Cornerstone that is the issue, but it is bad that there are no safeguards 
like transactional support to ensure that the database is never corrupted.

sqlite3 .svn/wc.db "pragma integrity_check"
*** in database main ***
Page 24268: btreeInitPage() returns error code 11
On tree page 6985 cell 3: Child page depth differs
On tree page 6985 cell 4: Child page depth differs
Error: database disk image is malformed


On Tuesday, November 15, 2011 10:39:56 AM UTC-7, Philip Martin wrote:
>
> Neil Bird > writes:
>
> >> Copy NODES_COPY into NODES:
> >> sqlite3 .svn/wc.db "insert into NODES select * from NODES_COPY"
> >
> >   Oops.  “Error: database disk image is malformed”.
> >
> >   Which is a bit odd, since we copied NODES to NODES_COPY OK, and have
> > since re-created NODES!
>
> Odd indeed.  Some sort of lazy, copy-on-write copy perhaps?  I think
> that means that the corruption extends beyond the indices into the nodes
> table, and that makes it very hard to recover.
>
> -- 
> Philip
>
>

RE: svn:externals - process question

[Andrew Reedick]

As you've discovered, externals *always* pull in the HEAD revision unless you 
specifically add a revision number to the svn:externals property.  Needless to 
say, "rogue" svn:externals are bad for build reproducibility and tagging.

Options are:
Audit the svn:externals (either manually, via a check-in hook, in the 
build/tagging script, etc.) in your checkedout/exported code to check for 
"rogue" svn:externals that are not locked down to a specific revision number.  
If there are "rogue" svn:externals, then you'll need to branch/tag and update 
the svn:externals before doing your build, or reject the code drop until the 
svn:externals are fixed.  Another similar alternative as you've stated, is to 
only allow svn:externals that point to tagged code.

If you want don't want to validate externals on the front end, you can try 
recording the externals after the fact.  If you do a checkout of the code, you 
can cd into each external and get the revision number (via svn info.)  Or you 
could parse the output of "svn co" or "svn export" to get the revision numbers 
of the externals items and record them somewhere.  ("svn update" will also 
return the revision numbers of externals.)  Ex:  Create the tag, run "svn co 
tag", record the revision numbers pulled in, go back and add "-r 123" to the 
svn:externals in the tag branch.  However, I haven't checked how nested 
externals are handled, e.g. your external reference could contain svn:externals 
which could have svn:externals of their own, ad infinitum.

A really simple option is to export the code (including externals) and then 
import the code again as its own tag.  Needless to say this breaks history, but 
it does guarantee that you can reproduce the build.

Using "--ignore-externals" isn't normally practical.

Partial Commits of an individual file?

[Andrew Thorburn]

I'm wondering if there has been any discussion about the ability to
commit bits and pieces of a file.

e.g.:

I have a particular bit of code in a project I'm working on which is
very large (too large), and I frequently need to make changes to it
for multiple issues. This means that when I go to commit, I have to
make a single commit which fixes or implements multiple issues. This
isn't really ideal, as it means that you can't look at the diffs of
the file to see which change applies to which issue - you just see a
nice big list of changes, and have to guess at what changes apply to
what issue.

I can't always commit straight away, as I need to wait for
confirmation that the fix is *actually* required, so I might move on
to the next issue which could require changes to the same file.

Ideally, I would like to be able to select the lines I want to commit
(or not commit, as the case may be), but as far as I'm aware, this
isn't possible with SVN, or any third-party tools? For what it's
worth, I currently use Subversive in Eclipse, and SVN 1.6 (not sure
exactly what version) as the client, and something really, really old
on the server.

Thanks,

- Andrew Thorburn

subversion dump question

[ANDREW . LUCAS]

Say you have multiple projects in one repository.

Is there an easy way to separate out one project tree, along with its
specific history, and move it to a new or different repository?

Thanks in advance, apologies if it's in the manual somewhere.

 

subscribe

[Andrew Sasak]

unlocking a svn:needs-lock file

[Andrew Schwartz]

Hi,

I'm using svn on Windows.

If a file with the svn:needs-lock property is currently locked and is
locally modified, I think that 'svn unlock' should fail.  I'm seeing it
happily succeed.

After the 'svn unlock', the local checkout is in a bad state: it has local
modifications to an unlocked svn:needs-lock file.

Is there a legitimate use case here that I'm not thinking of?

Thanks,

Andrew

svnsync: E160016: Path ... not present

[Andrew Reedick]

Anyone familiar with this svnsync bug/issue?  I didn't see anything substantive 
via google or in the svn issue tracker.
C:\>svnsync sync svn://localhost/devel_mirror
Transmitting file data ..
svnsync: E160016: Path 
'DigitalDelivery/DigitalSecure/ddp/aps/shared/apss-ddp-ejb/branches/apps-ddp-ejb-jboss-upgrade'
 not present


I have a master server (svn 1.8.3) pushing to a mirror (svn 1.8.11) and to a 
2nd mirror on my localhost (svn 1.8.10), both of which return the same E160016 
error when running svnsync sync.  To make things really interesting, the log 
entry on both mirrors for the missing directory is a tad off:

Master:
$ svn log -v -r 305908 http://my.svn.server/svn/devel

r305908 | jdoe | 2015-03-24 12:04:06 -0400 (Tue, 24 Mar 2015) | 1 line
Changed paths:
   A 
/DigitalDelivery/DigitalSecure/ddp/aps/shared/apss-ddp-ejb/branches/apps-ddp-ejb-jboss-upgrade




Mirror:
$ svn log -v -r 305908 
file:svn/csvn/data/repositories/devel_mirror.bad

r305908 | (no author) | (no date) | 1 line




Mirror Local:
C:\>svn log -v -r 305908 svn://localhost/devel_mirror

r305908 | (no author) | (no date) | 1 line




The dir doesn't exist on the mirrors, e.g.
C:\>svn ls 
svn://localhost/devel_mirror/DigitalDelivery/DigitalSecure/ddp/aps/shared/apss-ddp-ejb/branches/apps-ddp-ejb-jboss-upgrade
svn: warning: W160013: URL 
'svn://localhost/devel_mirror/DigitalDelivery/DigitalSecure/ddp/aps/shared/apss-ddp-ejb/branc
hes/apps-ddp-ejb-jboss-upgrade' non-existent in revision 309012
svn: E29: Could not list all targets because some targets don't 
exist
Thus, the sync fails when it tries to push a later revision that contains 
modified files under the "not present" directory.


So how does svnsync not correctly push a revision to two mirrors on two 
different computers?

RE: svnsync: E160016: Path ... not present

[Andrew Reedick]

> -Original Message-
> From: Andrew Reedick [mailto:jreed...@incomm.com] 
> Sent: Friday, April 24, 2015 1:26 PM
> To: users@subversion.apache.org
> Subject: svnsync: E160016: Path ... not present
> 
> Anyone familiar with this svnsync bug/issue?  I didn't see anything 
> substantive via google or in the svn issue tracker.
>   C:\>svnsync sync svn://localhost/devel_mirror
>   Transmitting file data ..
>   svnsync: E160016: Path 'DigitalDelivery/DigitalSecure/ddp/aps/
> shared/apss-ddp-ejb/branches/apps-ddp-ejb-jboss-upgrade' not present


Never mind.  It looks like the empty revisions were due to the sync user not 
initially having read access to that particular part of the tree.  So svnsync 
synchronized empty placeholder revisions.

Dealing with very old repo format (version 1)

[Andrew Reedick]

Does anyone have any tips on how to upgrade a very old repo?  The db/format 
lists "1".  A 1.8 svn client cannot hotcopy, dump or "svnadmin upgrade" such an 
old repo, all of which fail with "svnadmin: E720002: Can't open file 
'devel\db\current': The system cannot find the file specified."

Do I need find a really old svn client (1.3?) and upgrade?  Do I need to 
manually create the db/current file?


Supposedly , a format of "1" is from pre-svn 1.0.  
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h
 -> "Formats 0, 1 and 2 were pre-1.0."  

RE: Dealing with very old repo format (version 1)

[Andrew Reedick]

> -Original Message-
> From: Joseph Bruni [mailto:jbr...@icloud.com] 
> Sent: Tuesday, April 28, 2015 5:09 PM
> To: Andrew Reedick
> Cc: users@subversion.apache.org
> Subject: Re: Dealing with very old repo format (version 1)
>
> > On Apr 28, 2015, at 2:03 PM, Andrew Reedick  wrote:
> > 
> > Does anyone have any tips on how to upgrade a very old repo?  The db/format 
> > lists "1".  A 1.8 svn client cannot hotcopy, dump or "svnadmin upgrade" 
> > such an old repo, all of which fail with "svnadmin: > E720002: Can't open 
> > file 'devel\db\current': The system cannot find the file specified."
> > 
> > Do I need find a really old svn client (1.3?) and upgrade?  Do I need to 
> > manually create the db/current file?
> > 
> > 
> > Supposedly , a format of "1" is from pre-svn 1.0.  
> > https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h
> >  -> "Formats 0, 1 and 2 were pre-1.0."  
> > 
>
> Hi Andrew,
>
> I'm guessing your old format was built using the BerkeleyDB backend since 
> many of the earlist repos defaulted to BDB until FSFS came around. If you 
> build your svn with BDB, does it still complain?
>

Forgot to mention, "db\fs-type" is "fsfs" so BDB isn't (shouldn't) be an issuse.

On the plus side, I found some ancient installers:  
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=469&expandFolder=469&folderID=11149
  

RE: Dealing with very old repo format (version 1)

[Andrew Reedick]

> -Original Message-
> From: Andrew Reedick [mailto:jreed...@incomm.com] 
>
> > > On Apr 28, 2015, at 2:03 PM, Andrew Reedick  wrote:
> > > 
> > > Does anyone have any tips on how to upgrade a very old repo?  The 
> > > db/format lists "1".  A 1.8 svn client cannot hotcopy, dump or "svnadmin 
> > > upgrade" such an old repo, all of which fail with "svnadmin: > E720002: 
> > > Can't open file 'devel\db\current': The system cannot find the file 
> > > specified."
> > > 
> > > Do I need find a really old svn client (1.3?) and upgrade?  Do I need to 
> > > manually create the db/current file?
> > > 
> > > 
> > > Supposedly , a format of "1" is from pre-svn 1.0.  
> > > https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h
> > >  -> "Formats 0, 1 and 2 were pre-1.0."  
> > > 
> >
> > Hi Andrew,
> >
> > I'm guessing your old format was built using the BerkeleyDB backend since 
> > many of the earlist repos defaulted to BDB until FSFS came around. If you 
> > build your svn with BDB, does it still complain?
> >
>
> Forgot to mention, "db\fs-type" is "fsfs" so BDB isn't (shouldn't) be an 
> issuse.
>
> On the plus side, I found some ancient installers:  
> http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=469&expandFolder=469&folderID=11149
>   

Looks like the "fsfs" type was introduced in 1.1.  However, a 1.1.4 client 
fails with 
svn: Can't open file 'devel/db/current': The system cannot find the 
file specified.

And the 1.0.9 client fails with
svn: Berkeley DB error while opening 'nodes' table for filesystem devel 
- Copy/db:
No such file or directory

Looks like I need  a bigger hammer.

RE: Dealing with very old repo format (version 1)

[Andrew Reedick]

> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com] 

> Are we talking about the repository format or the FSFS format here? If 
> /db/fs-type says "fsfs" then the repository format
> (/format) is probably 3 and you're talking about /db/format, 
> yes? The distinction is important.

Yes, I'm referring to db/* files.
$ more format  fs-type
::
format
::
1
::
fs-type
::
fsfs

>
> In any case, 1.8 /should/ be able to dump an FSFSv1 repository, and the 
> /db/current file should exists; it's been around since FSFSv1.
> You can try recreating it; the format is described here:
>
> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
>
> To find the youngest revision, look for the highest-numered file in 
> /db/revs. If you're just going to dump the repository, it should be 
> safe to set the next-node-id and next-copy-id to some large number, say 
> 99; but I wouldn't recommend trying to commit to the repository.
>
> Please report if the above works or I'm just talking through my hat. :)
>
> -- Brane

Good News:  Recreating the db/current file worked in that it allowed 'svnadmin 
dump' to run.  

Bad News:  However, it seems that I have bigger issues:
* Dumped revision 109662.
svnadmin: E720002: Can't open file 'devel_copy\db\revprops\109663': The 
system cannot find the file specified.

When I sort the files in db/revs numerically, I see gaps in the revs:
109661
109662
109668
109734
...
109735
157939
157940
157941
159433 
159607 
160600 
160601
162409
And 'ls | wc -l' in dev/revs shows that there are 141,768 files, but the 
highest rev in db/revs is 162409...

*sigh*  I guess I can try piecemeal dumps.

Thanks for the help everyone, but I'm thinking my missing db/current file is a 
symptom of the repo being mangled (probably due to inadequate backup procedures 
or a bad restore from tape.   Rev 1 is from 2006, and the repo was just around 
for reference so no real worries.) 

RE: Svn rename doesn't copy custom properties

[Andrew Reedick]

Works for me.

svn, version 1.8.10 (r1615264)
Windows 7

C:\Users\jdoe\workspace\foobar>svn pl -v A.txt
Properties on 'A.txt':
  pebls:plcm
Test@4575
  pebls:sha1
8cd8818d6b4f5edcb8b6e25cdf471af62bca403c

C:\Users\jdoe\workspace\foobar>svn rename A.txt AA.txt
A AA.txt
D A.txt

C:\Users\jdoe\workspace\foobar>svn pl -v AA.txt
Properties on 'AA.txt':
  pebls:plcm
Test@4575
  pebls:sha1
8cd8818d6b4f5edcb8b6e25cdf471af62bca403c

C:\Users\jdoe\workspace\foobar>svn st
D   A.txt
> moved to AA.txt
A  +AA.txt
> moved from A.txt

From: Dan Ellis [mailto:danelli...@gmail.com]
Sent: Wednesday, April 29, 2015 7:23 PM
To: Daniel Shahaf
Cc: Subversion Users
Subject: Re: Svn rename doesn't copy custom properties

OK, so it gets stranger...

I admit I changed the property names a bit to simplify them.  When I ran the 
simplified names, it does work.

Here's the exact example that does not work:

c:\Project_files\sandbox_v2>svn pl -v A.txt
Properties on 'A.txt':
  pebls:plcm
Test@4575
  pebls:sha1
8cd8818d6b4f5edcb8b6e25cdf471af62bca403c

c:\Project_files\sandbox_v2>svn rename A.txt AA.txt
A AA.txt
D A.txt

c:\Project_files\sandbox_v2>svn pl -v AA.txt

c:\Project_files\sandbox_v2>svn pl -v REN.txt

RE: Svn rename doesn't copy custom properties

[Andrew Reedick]

> From: Dan Ellis [mailto:danelli...@gmail.com] 
>
> **Brane asked: There's no REN.txt in your example. 
> **Anyway, please tell us which version of the client you're using (svn  
> --version) and where it came from. 
>
> I meant to exclude that as its not relevant, was trying to point out the 
> empty response.
> Sorry everyone, I'm not on the mailing list proper, I'd appreciate being cc:d.
> This is the client version, being whatever was packaged with the version of 
> TSVN.
>
> svn, version 1.8.9 (r1591380)
>   compiled May  6 2014, 20:28:35 on x86-microsoft-windows

Maybe there's a problem with inherited properties that ignore certain files or 
Something(tm)?

Can you create a new (empty) repo and re-run the test in it?

RE: Subversion for Windows

[Andrew Reedick]

SubversionEdge from collabnet is a pre-packaged solution that takes most of the 
effort out of setting up svn + http/https:  
http://www.collab.net/products/subversion


From: Novinsky, Stanley J. [mailto:stan.novin...@jhuapl.edu]
Sent: Wednesday, May 06, 2015 5:54 PM
To: users@subversion.apache.org
Subject: Subversion for Windows

Hi,

I have a question,,,
I Installed Subversion for Windows on a VM and set up a project using 
TortoiseSVN
We need to access the SVN from remote offices vis https
What is the process to set up the remote access allowing users to access the 
project?

Thanks

Stan

RE: Tool for upgrading many svn repos with dump/load?

[Andrew Reedick]

Since you're moving from windows to Ubuntu, you can run the dump/load process 
over ssh to avoid having to deal with bloated dump files:  
http://martin.ankerl.com/2006/01/24/svnadmin-dump-and-load-over-ssh/  (You can 
use mobaxterm (http://mobaxterm.mobatek.net/ ) on Windows, which is a Cygwin 
bash shell in a self contained exe.  Very, very  convenient.)

You can also use ssh to create the empty repos remotely.

As for merging the configurations, short of creating a temp repo in which you 
check in the default repo's auth/conf/hook files into trunk, and then checking 
in your live repo auth/conf/hook scripts into a branch off of trunk, then 
merging the branch into the trunk to effectively merge the files and then 
copying the merged files to the new repos, I don't know of anything.  =(



-Original Message-
From: Thorsten Schöning [mailto:tschoen...@am-soft.de] 
Sent: Friday, July 10, 2015 3:53 AM
To: users@subversion.apache.org
Subject: Tool for upgrading many svn repos with dump/load?

Hi all,

are you aware of any tool that is able to upgrade many SVN repos by creating a 
new empty default repo, dump a corresponding old repo, load that dump into the 
new one AND is able to MERGE the configuration? I have some dozen repos hosted 
by svnserve with independent realms, users, authz rules and such. This 
configuration could be just copied, but I would prefer merged default configs 
for documentation purpose and such.

I've created something similar in the past using Powershell, but without the 
merge stuff and it just don't work on our now used Ubuntu servers. Before I 
roll my own new script, I wanted to make sure that I don't miss anything 
because I didn't found something mentioned on the net.

Thanks!

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

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

RE: Two-step merge ok, one-step merge conflicts

[Andrew Reedick]

> -Original Message-
> From: Timur Khanipov [mailto:khani...@gmail.com] 
> Sent: Wednesday, August 19, 2015 1:20 PM
> To: users@subversion.apache.org
> Cc: Иван Коптелов
> Subject: Two-step merge ok, one-step merge conflicts
>
> Hi folks.
>
> I faced the following problem. The command
>   svn merge -r 3:4 -r 4:5 ^^/trunk
> works smoothly while command
>   svn merge -r 3:5 ^^/trunk
> results in a text conflict. This seems like a buggy behavior (since the two 
> merges are equivalent).

Same behavior in 1.8.10 (r1615264) on windows.

However, if you change the svn:eol-style to "CRLF", them "merge -r 3:5" works 
without a conflict.

It looks like "native" with the "merge -r 3:5" causes a conflict because of eol 
changes to the file in the middle of the merge process?  Also note, that with 
"native" the merge conflict appears to be with the EOLs and not with the text 
change you made.

RE: preventing recording misaligned mergeinfos

[Andrew Reedick]

I was under the impression that subversion now automatically takes subtree 
mergeinfo into account:  
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.stayinsync.subtree


-Original Message-
From: Stefan Hett [mailto:ste...@egosoft.com] 
Sent: Friday, August 28, 2015 9:19 AM
To: 'subversion'
Subject: preventing recording misaligned mergeinfos

Hi,

I'm currently checking-out ways to prevent the creation of misaligned 
mergeinfos in SVN. My current solution would be to add a pre-commit hook to 
prevent any mergeinfo records on any but the top-most node (aka: 
trunk or a branch). While this would prevent most cases which let to misaligned 
mergeinfos, it's certainly not exactly what I want/need.

Does anybody have an idea for a better/more precise solution/approach?

--
Regards,
Stefan Hett, Developer/Administrator

EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473

RE: could subversion server 1.7.x work with subverison client 1.8.x ?

[Andrew Reedick]

Go here https://subversion.apache.org/docs/release-notes select a release and 
then look at the “Feature Compatibility Table” which will specify which 
features require what server/client version.

However, as already noted, basic features will work with any 1.x client and 1.x 
server.

From: Leon Huang [mailto:hzlian...@gmail.com]
Sent: Sunday, September 27, 2015 9:56 AM
To: users@subversion.apache.org
Subject: could subversion server 1.7.x work with subverison client 1.8.x ?

Dear developers of subversion:
 Hello!
 Question 1: If the version of subversion server is 1.7.10, but my 
subversion client is 1.8.5, is there any problem?

 Question 2: At first,  use subversion 1.7.10 client to checkout a 
work-copy. Then subversion 1.8.x client to upgrade the work-copy from 1.7 to 
1.8,  from then on I just use subversion 1.8.x client to operate this 
work-copy,  is it compatible？

  I hope that you can help me! Thank you!
  Looking forward to your reply!
  Have a nice day!

  Regards！



From Leon Huang
Hangzhou
China

RE: which version control supports file locking and who has it locked

[Andrew Reedick]

> From: Doug Robinson [mailto:doug.robin...@wandisco.com] 
> Sent: Monday, June 13, 2016 4:49 PM
> To: Johan Corveleyn
> Cc: Mark McKeown; Andreas Stieger; users@subversion.apache.org
> Subject: Re: which version control supports file locking and who has it locked
>
>
> I'm not sure about Perforce's implementation.  However, just for
> comparison: with ClearCase Dynamic Views you can *not* edit the file
> without a checkout.  The Dynamic View implementation is via an actual
> OS file system so you can't beat it.  And everyone can see that checkout.


What about eclipsed files?

And never forget that Someone can always copy the file out of the 
view/workspace to make changes to it because they're in a rush to leave for 
vacation.  Of course such a person, after coming back from vacation, would 
*never* copy their week old modified file back in to the workspace/view in 
order to check in their changes after the lock is released thus undoing the 
previous week's work of commits. 

Point is, you can't completely idiot proof anything because there's always one 
idiot who's smarter than you.

RE: Creating and Verifying a Reliable backup

[Andrew Reedick]

> From: Michael Schwager [mailto:mschw...@gmail.com] 
> Sent: Wednesday, June 22, 2016 10:25 AM
> To: users@subversion.apache.org
> Subject: Re: Creating and Verifying a Reliable backup
>
> Following is an update to my question of Jun 1, where I ask the following 
> question:
>
... snip verify/backup/verify/rsync/verify script...
>

If you're not already doing it, you might want to pack your repos in order to 
the make the backups and/or copying faster.  Working on thousands of small 
files is incredibly slow/inefficient.
http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.fsfspacking

However, I'm not sure what the pros/cons of packing are in regards to rsync.

RE: [Linux] Hook hashbang hardships

[Andrew Reedick]

> Hello! I've been having trouble getting my own pre-revprop-change hook script 
> to work. Svn was refusing any change to a revprop with the following error:
> 
> svn: E165001: Revprop change blocked by pre-revprop-change hook (exit code 1) 
> with no output.
> 
>
> Until I found out that the issue was in the script's shebang:
>
>   #!/bin/bash -e
>
> which wouldn't work. Had to remove ' -e'. Is this expected behaviour or is 
> there something wrong with svn (version 1.9.4 (r1740329) on
> Linux/x86_64) ?


Bash doesn't appear to have a "-e" option.  (There is a "-e" test to check if a 
path exists, but that's not a command line arg you pass in to bash.)

/bin/bash --help
man bash
https://linux.die.net/man/1/bash

RE: [Linux] Hook hashbang hardships

[Andrew Reedick]

> -Original Message-
> From: Branko Čibej [mailto:br...@apache.org] 
> Sent: Friday, October 14, 2016 9:38 AM
> To: users@subversion.apache.org
> Subject: Re: [Linux] Hook hashbang hardships
>
> On 14.10.2016 14:58, Andrew Reedick wrote:
> >> Hello! I've been having trouble getting my own pre-revprop-change hook 
> >> script to work. Svn was refusing any change to a revprop with the 
> >> following error:
> >> 
> >> svn: E165001: Revprop change blocked by pre-revprop-change hook (exit code 
> >> 1) with no output.
> >> 
> >>
> >> Until I found out that the issue was in the script's shebang:
> >>
> >>#!/bin/bash -e
> >>
> >> which wouldn't work. Had to remove ' -e'. Is this expected behaviour or is 
> >> there something wrong with svn (version 1.9.4 (r1740329) on
> >> Linux/x86_64) ?
> >
> > Bash doesn't appear to have a "-e" option.  (There is a "-e" test to check 
> > if a path exists, but that's not a command line arg you pass in to bash.)
> >
> > /bin/bash --help
> > man bash
> > https://linux.die.net/man/1/bash
>
>
> You really need to read the manpage, which says:
>
> All  of  the   single-character  shell  options  documented  in the
> description of the *set* builtin command can be used as options when
> the shell is invoked.


Let's go all the way down the rabbit hole:  http://ss64.com/bash/set.html

-e  Exit immediately if a simple command exits with a non-zero status, unless
   the command that fails is part of an until or  while loop, part of an
   if statement, part of a && or || list, or if the command's return status
   is being inverted using !.  -o errexit

Plan B; add -x to see what's going on:  #!/bin/bash -ex

Backup using ZFS Snapshots

[Andrew Martin]

Hello,

I am running a Subversion 1.9.3 server on Ubuntu 16.04. I currently use
svnadmin hotcopy to safely backup the SVN repositories, but since the
repositories are now hosted on a ZFS dataset, I would like to utilize ZFS's
snapshot capabilities to create atomic, point-in-time backups of the
repositories. My plan to do this is as follows:

1. create zfs snapshot
2. clone zfs snapshot and mount at a temporary location
3. run svnadmin hotcopy from the mounted clone to safely create a backup
4. umount and destroy clone

My only concern is if a commit is in-progress when the zfs snapshot occurs, 
would svnadmin hotcopy still be able to safely handle creating the backup? 

Is this a safe procedure for creating backups?

Thanks,

Andrew Martin

Re: Backup using ZFS Snapshots

[Andrew Martin]

- Original Message -
> From: "Stefan Sperling" 
> To: "amartin" 
> Cc: "users" 
> Sent: Tuesday, December 13, 2016 3:29:50 PM
> Subject: Re: Backup using ZFS Snapshots

> On Tue, Dec 13, 2016 at 03:17:53PM -0600, Andrew Martin wrote:
>> Hello,
>> 
>> I am running a Subversion 1.9.3 server on Ubuntu 16.04. I currently use
>> svnadmin hotcopy to safely backup the SVN repositories, but since the
>> repositories are now hosted on a ZFS dataset, I would like to utilize ZFS's
>> snapshot capabilities to create atomic, point-in-time backups of the
>> repositories. My plan to do this is as follows:
>> 
>> 1. create zfs snapshot
>> 2. clone zfs snapshot and mount at a temporary location
>> 3. run svnadmin hotcopy from the mounted clone to safely create a backup
>> 4. umount and destroy clone
>> 
>> My only concern is if a commit is in-progress when the zfs snapshot occurs,
>> would svnadmin hotcopy still be able to safely handle creating the backup?
>> 
>> Is this a safe procedure for creating backups?
> 
> You don't need to hotcopy at all if you have filesystem snapshots.
> Check out 'svnadmin freeze'. It was made for this use case.

Thanks for the quick reply - 'svnadmin freeze' looks useful for this purpose.

Is there a way to freeze the repository with a command and then unfreeze it
with another command? I'd ideally like to run several commands on different
servers while the repository is frozen.

Re: Backup using ZFS Snapshots

[Andrew Martin]

- Original Message -
> From: "Mark Phippard" 
> To: "amartin" 
> Cc: "users" 
> Sent: Tuesday, December 13, 2016 3:35:37 PM
> Subject: Re: Backup using ZFS Snapshots

> On Tue, Dec 13, 2016 at 4:17 PM, Andrew Martin  wrote:
> 
>> Hello,
>>
>> I am running a Subversion 1.9.3 server on Ubuntu 16.04. I currently use
>> svnadmin hotcopy to safely backup the SVN repositories, but since the
>> repositories are now hosted on a ZFS dataset, I would like to utilize ZFS's
>> snapshot capabilities to create atomic, point-in-time backups of the
>> repositories. My plan to do this is as follows:
>>
>> 1. create zfs snapshot
>> 2. clone zfs snapshot and mount at a temporary location
>> 3. run svnadmin hotcopy from the mounted clone to safely create a backup
>> 4. umount and destroy clone
>>
>> My only concern is if a commit is in-progress when the zfs snapshot occurs,
>> would svnadmin hotcopy still be able to safely handle creating the backup?
>>
> 
> svnadmin hotcopy will not have a problem with an in-process commit.  That
> is kind of one of the points of that command.
> 
> 
> 
>> Is this a safe procedure for creating backups?
>>
> 
> I know very little about ZFS but I do not understand why you would do
> this.  If it can take snapshots, then why wouldn't you just take a snapshot
> of the actual live repository, why would you want to copy it?
> 
> Setting that aside, I think hotcopy is a very good way to do backups ...
> but it is not clear what value would come from taking a snapshot of the
> backup given that version control history is immutable etc.  Also, once you
> create the initial hotcopy, you can use the hotcopy --incremental option to
> just copy the newer revisions.  Do that from a post-commit hook and you can
> always have a backup up to the latest commit.
> 
> To me snapshots would seem like a way to do backups without using hotcopy.
> I am not sure the value of combining the two ... but it should work
> technically if you have "reasons".
> 
> Mark

The reason I want to do it this way is that I want to "pull" the backups to
the backup server rather than "pushing" them from the Subversion server. In
order to do that, I plan on mounting the clone over NFS on the backup server
and then using "svnadmin hotcopy" to pull any new data onto the backup server.
Yes, I could just mount the live repository, but I have a number of repositories
to backup and using the ZFS snapshot ensures that they are all from a single
point-in-time.

It sounds like "svnadmin hotcopy" will just ignore any in-progress commit, so
even if the ZFS snapshot happened in the middle of a commit, it would still
result in a consistent backup.

Thanks,

Andrew

Re: Backup using ZFS Snapshots

[Andrew Martin]

- Original Message -
> From: "Mark Phippard" 
> To: "amartin" 
> Cc: "users" 
> Sent: Tuesday, December 13, 2016 3:57:04 PM
> Subject: Re: Backup using ZFS Snapshots

> On Tue, Dec 13, 2016 at 4:47 PM, Andrew Martin  wrote:
> 
>>
>>
>> - Original Message -
>> > From: "Mark Phippard" 
>> > To: "amartin" 
>> > Cc: "users" 
>> > Sent: Tuesday, December 13, 2016 3:35:37 PM
>> > Subject: Re: Backup using ZFS Snapshots
>>
>> > On Tue, Dec 13, 2016 at 4:17 PM, Andrew Martin 
>> wrote:
>> >
>> >> Hello,
>> >>
>> >> I am running a Subversion 1.9.3 server on Ubuntu 16.04. I currently use
>> >> svnadmin hotcopy to safely backup the SVN repositories, but since the
>> >> repositories are now hosted on a ZFS dataset, I would like to utilize
>> ZFS's
>> >> snapshot capabilities to create atomic, point-in-time backups of the
>> >> repositories. My plan to do this is as follows:
>> >>
>> >> 1. create zfs snapshot
>> >> 2. clone zfs snapshot and mount at a temporary location
>> >> 3. run svnadmin hotcopy from the mounted clone to safely create a backup
>> >> 4. umount and destroy clone
>> >>
>> >> My only concern is if a commit is in-progress when the zfs snapshot
>> occurs,
>> >> would svnadmin hotcopy still be able to safely handle creating the
>> backup?
>> >>
>> >
>> > svnadmin hotcopy will not have a problem with an in-process commit.  That
>> > is kind of one of the points of that command.
>> >
>> >
>> >
>> >> Is this a safe procedure for creating backups?
>> >>
>> >
>> > I know very little about ZFS but I do not understand why you would do
>> > this.  If it can take snapshots, then why wouldn't you just take a
>> snapshot
>> > of the actual live repository, why would you want to copy it?
>> >
>> > Setting that aside, I think hotcopy is a very good way to do backups ...
>> > but it is not clear what value would come from taking a snapshot of the
>> > backup given that version control history is immutable etc.  Also, once
>> you
>> > create the initial hotcopy, you can use the hotcopy --incremental option
>> to
>> > just copy the newer revisions.  Do that from a post-commit hook and you
>> can
>> > always have a backup up to the latest commit.
>> >
>> > To me snapshots would seem like a way to do backups without using
>> hotcopy.
>> > I am not sure the value of combining the two ... but it should work
>> > technically if you have "reasons".
>> >
>> > Mark
>>
>> The reason I want to do it this way is that I want to "pull" the backups to
>> the backup server rather than "pushing" them from the Subversion server. In
>> order to do that, I plan on mounting the clone over NFS on the backup
>> server
>> and then using "svnadmin hotcopy" to pull any new data onto the backup
>> server.
>> Yes, I could just mount the live repository, but I have a number of
>> repositories
>> to backup and using the ZFS snapshot ensures that they are all from a
>> single
>> point-in-time.
>>
>> It sounds like "svnadmin hotcopy" will just ignore any in-progress commit,
>> so
>> even if the ZFS snapshot happened in the middle of a commit, it would still
>> result in a consistent backup.
>>
>>
> Yes, hotcopy will leave you with a consistent repository at the state it
> was in when the backup started.  Any commits that are in process will not
> be copied/included in the backup.  The problem with hotcopy, is that unless
> you craft a method where you can use --incremental, you are copying the
> entire repository every time you do a backup even though only a small
> number of new files may have been created.  The SVN repository format is
> write-once.  Only new files get added as new revisions get created.  So the
> repository can be backed up very efficiently if you just keep capturing the
> new revisions being created.
> 

Yes I plan on using --incremental to make the backup very quick. Basically the
steps will be:
1. make snapshot on fileserver
2. clone snapshot to read-only clone, accessible by backup server over NFS
3. mount clone on backup server
4. run svnadmin hotcopy --incremental on clone
5. unmount and delete clone

Since I'll be pointing "svnadmin hotcopy" at the same target directory on
the backup server each time this is run, I should be able to to take advantage
of --incremental to make this fast.

> If all of your activity happens via Apache there might be easier ways to make 
> all your repositories read only during a backup window and you can also always
> use the start-commit hook as an easy way to make repositories read only.

It's tempting to just stop apache during the backup, but I need to continue to
provide read-only access during the backup window, so apache needs to stay on. 
Yes
I could update the authz file and change all entries from rw to r, but that 
seems
trickier given that I have a large authz file.

Re: Backup using ZFS Snapshots

[Andrew Martin]

- Original Message -
> From: "Mark Phippard" 
> To: "amartin" 
> Cc: "users" 
> Sent: Thursday, December 15, 2016 8:40:43 AM
> Subject: Re: Backup using ZFS Snapshots

> On Thu, Dec 15, 2016 at 9:25 AM, Andrew Martin  wrote:
> 
>> > If all of your activity happens via Apache there might be easier ways to
>> make
>> > all your repositories read only during a backup window and you can also
>> always
>> > use the start-commit hook as an easy way to make repositories read only.
>>
>> It's tempting to just stop apache during the backup, but I need to
>> continue to
>> provide read-only access during the backup window, so apache needs to stay
>> on.
>>
> 
> I was thinking of two approaches:
> 
> 1.  Have a "read-only" Apache httpd.conf that you swap into place and do a
> graceful restart and then swap back at end.  This configuration would use
> some variant of these directives I took from the svnbook:
> 
>  # Authorization: Authenticated users only for non-read-only
>  #(write) operations; allow anonymous reads
>  
>Require valid-user
>  
> 
> You would use this concept, not this exact configuration.  You would want
> basically be configuring the server to only allow read options.
> 
> 
> 2. The easier approach is the start-commit hook.  Just have a single master
> hook-script that all repositories are symlinked to.  Assuming you do not
> use this hook for anything else, you can just have it in place with content
> like:
> 
> exit 0;
> 
> Then when you are doing a backup you change it to something like:
> 
> echo "Server is in read-only mode for backup. It should be available again
> within N minutes"
> exit 1;
> 
> That said, based on the approach you are taking, I do not think you need to
> do any of this.  Your ZFS snapshot of the filesystem can happen while a
> commit is happening since the ultimate backup will be done with an svnadmin
> hotcopy and that command will not care if the snapshot grabbed an
> in-progress commit.
> 
Thanks for the clarification - those both seem like good approaches as well,
but like you said the ZFS snapshot + "svnadmin hotcopy" should be sufficient
for my particular use case.

Thanks again for the help!

Andrew

RE: how to detect read-only branch from client?

[Andrew Reedick]

Not a complete solution, but it's a start.  Craft a "svn mkdir" that includes 
the url to test and a url that will always fail, e.g.
svn mkdir -m "" http://server/repo/dir2test/a  
http://server/repo/readonly/z

However, it looks like the urls are sorted and then processed in sort order 
(including for svnmucc.)  So you need your test url to come before your "will 
always fail" readonly url.  Getting the sorting figured out is left an exercise 
to the reader.  Maybe someone else knows of a way to ensure that the "always 
fail" readonly url gets checked last regardless of windows sorting, linux 
sorting, LC_ALL/LC_COLLATE settings, etc.


-Original Message-
From: Torsten Mueller [mailto:muelle...@runbox.com] 
Sent: Monday, February 13, 2017 11:51 AM
To: users@subversion.apache.org
Subject: how to detect read-only branch from client?

I write a script getting sources from one repository, doing a build and other 
time consuming things and then committing the results into another repsitory.

The problem is: the detination side is "managed" which means that I must expect 
read only branches there. They use the path based authentication feature (see 
VisualSVNServer) without any communication. They want to close a branch for 
commits, that's enough communication.

But in my case it would be very bad to start a process which runs for an hour 
or longer and then fails because it can't do the final commit.

How can I detect if a path in the destination directory is read only without 
modifying it?

My first guess was to use "svnmucc propdel" to delete a property which doesn't 
exist. This works great on a branch which is read only. But on the other side 
it creates always a revision on normal branches. That's not good. What can I do?

T.M.

RE: How to checkout only the changes

[Andrew Reedick]

> From: horst.schl...@gmx.de [mailto:horst.schl...@gmx.de] 
> Sent: Friday, March 24, 2017 4:04 PM
> To: users@subversion.apache.org
> Subject: How to checkout only the changes
>
>
> Is there a way to export only the changes, that occured in a specific 
> revision? Like export or checkout only the added or modified files in their 
> respective paths? Deletions and cheap copies cannot be treated that way, 
> obviously. Please CC as I am not subscribed.

FYI, 'svn copy' counts as an Add.  That may or may not be a concern?

Mostly Untested But Seems to Work in the Average Case(tm), so user beware:

#!/bin/bash

# usage:  foo.sh 1234   http://svn_server/repo_name
REV=$1
SVNREPO=$2

svn log -qv -r $REV $SVNREPO 

# Yes we're grepping on XML because :laziness:
# And we're using perl because I can't be bothered with sed/awk subtleties 
svn log -qv --xml -r $REV "$SVNREPO" | perl -ne 'chomp; $a=1 if /^   
action="[AD]"/; print "$1\n" if ( $a && /^   kind="file">(.*)<\/path>/ ); $a=0 
if /<\/path>/;' | while read i
do 
D=./`dirname "$i"`
mkdir -p "$D"
svn export --force "$SVNREPO/$i@$REV" "$D/"
done

RE: How to checkout only the changes

[Andrew Reedick]

New and improved and simplified version.  Uses 'svn log --diff' to get the 
files that changed.
Again, only lightly tested.  (The previous script assumed that the order of the 
xml attributes didn't change and it did.  Ooops.)
I used perl instead of sed due to sed version silliness in regards to tabs; so 
feel free to the perl equivalent sed commands to remove the trailing "\t 
(revision 12345)" from the "svn log --diff ... | grep '^+++' " output.
Remove the two echo commands to actually run the mkdir/export commands.

Edge case:  I didn't test how 'svn log --diff' handles deleted files.

#!/bin/bash

REV=$1
SVNREPO=$2

svn log --diff -r $REV "$SVNREPO"  | grep '^+++' | perl -pe 's/^\+\+\+ //; 
s/\t.*$//' | while read i
do
D=./`dirname "$i"`
echo mkdir -p "$D"
echo svn export --force "$SVNREPO/$i@$REV" "$D/"
done




-Original Message-
From: horst.schl...@gmx.de [mailto:horst.schl...@gmx.de] 
Sent: Wednesday, March 29, 2017 9:28 PM
To: users@subversion.apache.org
Subject: Re: How to checkout only the changes

On 03/27/2017 10:08 AM, Andrew Reedick wrote:
>> From: horst.schl...@gmx.de [mailto:horst.schl...@gmx.de]
>> Sent: Friday, March 24, 2017 4:04 PM
>> To: users@subversion.apache.org
>> Subject: How to checkout only the changes
>>
>>
>> Is there a way to export only the changes, that occured in a specific 
>> revision? Like export or checkout only the added or modified files in their 
>> respective paths? Deletions and cheap copies cannot be treated that way, 
>> obviously. Please CC as I am not subscribed.
>
> FYI, 'svn copy' counts as an Add.  That may or may not be a concern?
>
> Mostly Untested But Seems to Work in the Average Case(tm), so user beware:
>
> #!/bin/bash
>
> # usage:  foo.sh 1234   http://svn_server/repo_name
> REV=$1
> SVNREPO=$2
>
> svn log -qv -r $REV $SVNREPO
>
> # Yes we're grepping on XML because :laziness:
> # And we're using perl because I can't be bothered with sed/awk subtleties
> svn log -qv --xml -r $REV "$SVNREPO" | perl -ne 'chomp; $a=1 if /^   
> action="[AD]"/; print "$1\n" if ( $a && /^   kind="file">(.*)<\/path>/ ); 
> $a=0 if /<\/path>/;' | while read i
> do
>   D=./`dirname "$i"`
>   mkdir -p "$D"
>   svn export --force "$SVNREPO/$i@$REV" "$D/"
> done
>

The script just drops to the shell with exit code 0. My perl knowledge is very 
limited, but to debug I executed this

$ echo "action=\"A\">/trunk/text.txt" | perl -ne 'chomp; $a=1 if /^ 
action="[AD]"/; print "$1\n" if ( $a && /^ kind="file">(.*)<\/path>/ ); $a=0 if 
/<\/path>/;'

I assume that is supposed to do something but for me it just drops to the shell 
with exit code 0.

RE: How to checkout only the changes

[Andrew Reedick]

> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
> Sent: Thursday, March 30, 2017 3:41 PM
> To: Andrew Reedick
> Cc: horst.schl...@gmx.de; users@subversion.apache.org
> Subject: Re: How to checkout only the changes
>
> 'vsvn diff --summarize' or 'svn log -qv' would be better.  (They're O(1) as 
> opposed to O(revision size).)


Unfortunately, neither one differentiates between directories and filenames 
(unless you go with --xml.)  And exporting a dir will grab a bit more than what 
we wanted.  Unless of course the contents of new directories count as changes.  
Which would be a requirements question for the OP.

RE: svn feature addition?

[Andrew Reedick]

> From: Eggler, Ron (GE Energy Connections) [mailto:ron.egg...@ge.com] 
> Sent: Thursday, June 1, 2017 7:44 PM
> To: users@subversion.apache.org
> Subject: svn feature addition?
>
> Hi There,
>
> I am looking for the following features in svn:
> - When you do svn commit, instead of automatically submitting all changed 
> files in the directory, in the dialog where you enter the commit message (if 
> -m flag is not used), is there a feature to uncheck any files that should not 
> be committed/select files to be committed? 
> - Is there an option to inspect each file further line-by-line for lines  
> that have changed to either be selected or excluded from the commit?
> I am interested to potentially work on patches that would extend svn with the 
> above functionality if not present already, does anyone know? It seems like 
> these options would be really useful.

What about working on a (temp) branch and then selectively merging what you 
want over?

Steps would be:
Make temp branch
Switch to temp branch
Commit all
Switch to main branch 
Selectively merge files/lines from temp to main
Commit main.
"Copy merge" from temp to main to overwrite workspace with stuff from temp in 
order to recreate modified files (i.e. files that you only merged a few lines 
from) that existed initially.   
Rm temp branch
Keep working.

Most of that should be scriptable.

RE: svn vs. git

[Andrew Reedick]

It’s been awhile, but isn’t changing the commit message (after a push) 
potentially problematic in git?

RE: upgrading server

[Andrew Reedick]

>> Does anyone know how long it would take to export the repository of this 
>> size?  This will give us an estimate how long to schedule down time and cut 
>> off time.

Svnsync is the easy option.

If you insist on doing a dump/load, then a) you can time a test run of a 
dump/load, and b) "svnadmin dump" allows you to specify revision ranges which 
means you can do incremental dumps.  You can dump/load the bulk of the repo now 
and then during the migration, run another dump/load to catch any new commits.
http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate

The only caveat I can think of is if someone changes revision properties (e.g. 
the commit message) between the time of the initial dump and the migration.  
But you can track/prevent those with a hook script.  (And is another reason why 
svnsync is preferred.)

RE: Individual file merge . Merging a newly added file

[Andrew Reedick]

> -Original Message-
> From: Lorenz [mailto:loren...@yahoo.com] 
> Sent: Wednesday, August 2, 2017 1:34 AM
> To: users@subversion.apache.org
> Subject: Re: Individual file merge . Merging a newly added file
>
> JP wrote:
> >I am trying to merge a newly added file  . I am getting the following 
> >error .
> >
> >|svn merge -c123 
> >|https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.sv
> >|n.domain%2Fsvn%2Ffoo%2Fbranches%2Fbar%2Fnewfile.txt&data=02%7C01%7Cjre
> >|edick%40incomm.com%7Cbf08bacf2e7f48e9062108d4d9683be1%7Cd08e5403b1c94d
> >|bfaf91bab966a84dea%7C1%7C0%7C636372489093013309&sdata=%2BS0P8L4moTaajr
> >|L5XQS%2BIc4ln8hyEci1GdDKhYkh1eE%3D&reserved=0 ./newfile.txt
> >svn: E29: Merge target './newfile.txt' does not exist in the 
> >working copy
> >
> >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.svn.domain%2Fsvn%2Ffoo%2Fbranches%2Fbar%2Fnewfile.txt&data=02%7C01%7Cjreedick%40incomm.com%7Cbf08bacf2e7f48e9062108d4d9683be1%7Cd08e5403b1c94dbfaf91bab966a84dea%7C1%7C0%7C636372489093013309&sdata=%2BS0P8L4moTaajrL5XQS%2BIc4ln8hyEci1GdDKhYkh1eE%3D&reserved=0
> > is in status "A" 
> >.  How can I do such merges .
>
>
> adding a file is a change to the parent directory.

Translation:  The newly added newfile.txt is completely unrelated to the 
previously existing newfile.txt you are merging from.

Either 
a) Remove the newly added newfile.txt and instead do a 'svn copy ...' of the 
previously existing newfile.txt to the new location.  This preserves ancestry 
and makes merging easier.
Or
b) If the newly added newfile.txt really should be completely 
independent/unrelated to the previously existing newfile.txt, then you will 
need to use a "2-URL merge" to merge the previously existing newfile.txt into 
the newly added newfile.txt.  Refer to "svn help merge".


>From "svn help merge":
  3. This form is called a '2-URL merge':
...
The target branch may be the same as one or both sources, or different again.
 The three branches involved can be completely unrelated.

svn version 1.10 lack of robustness in presence of flaky network

[Marlow, Andrew]

Hello everyone,

I got this error below during an svn co command. It left my workspace in a bad 
state from which I had to do svn cleanup before trying again (the retry worked):

svn: E200033: Another process is blocking the working copy database, or the 
underlying filesystem does not support file locking; if the working copy is on 
a network filesystem, make sure file locking has been enabled on the file server
svn: E200033: sqlite[S5]: database is locked
svn: E200042: Additional errors:
svn: E200033: sqlite[S5]: database is locked
svn: E200030: sqlite[S1]: cannot start a transaction within a transaction
svn: E200030: sqlite[S1]: cannot start a transaction within a transaction

I think this happens when the network is flaky. This error happened on windows 
but I have also seen it happen on solaris 10.  Has anyone else seen this? If it 
is due to network flakiness then perhaps svn should retry to work around this 
transparently, and thus be more robust? Perhaps it could retry up to 3 times 
with a sleep a 1 second between retries?

Andrew Marlow
Consultant developer, Apex
38th Floor, 25 Canada Square,
Canary Wharf, London E14 5LQ
T:  020-8081-2367 / 07966-451-521
E: andrew.mar...@fisglobal.com<mailto:andrew.mar...@fisglobal.com>
FIS | Empowering the Financial World [cid:image001.png@01D112FA.C4A77D90] 
<https://www.facebook.com/FIStoday> [cid:image002.png@01D112FA.C4A77D90] 
<https://twitter.com/FISGlobal> [cid:image003.png@01D112FA.C4A77D90] 
<https://www.linkedin.com/company/fis>
FIS Apex (UK) Limited * Registered in England and Wales No. 3573008 * 
Registered Office: 38th floor, 25 Canada Square, London, E14 5LQ, United Kingdom
[50_3]

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. FIS is a trading name of the following 
companies: Fidelity Information Services Ltd (registered in England 
No.02225203), FIS Payments (UK) Ltd (No.04215488), FIS Asiapacrim Holdings Ltd 
(No.06707320), Certegy Card Services Ltd (No.03517639) and Efunds International 
Ltd (No.01930117), all with their registered office at Floor 1, 51/53 Hagley 
Road, Birmingham B16 8TU, United Kingdom; and FIS Payments (Ireland) Ltd 
(registered in Ireland No.126879), with its registered office at 25/28 North 
Wall Quay, Dublin 1, D01 H104, Ireland. FIS Payments (UK) Ltd is authorised and 
regulated by the Financial Conduct Authority; some services are covered by the 
Financial Ombudsman Service (in the UK). Calls to and from the companies may be 
recorded for quality purposes. All of the above companies are part of FIS 
(Fidelity National Information Services Inc.).

RE: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network

[Marlow, Andrew]

Reply below:

-Original Message-
From: Stefan Sperling 
Sent: 24 April 2019 07:54
To: Marlow, Andrew 
Cc: Johan Corveleyn ; users@subversion.apache.org
Subject: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky 
network

On Wed, Apr 24, 2019 at 12:55:47AM +0200, Johan Corveleyn wrote:
> On Mon, Apr 22, 2019 at 9:22 AM Marlow, Andrew
>  wrote:
> > Hello everyone,
> > I got this error below during an svn co command. It left my workspace in a 
> > bad state from which I had to do svn cleanup before trying again (the retry 
> > worked):
[snip]
> > I think this happens when the network is flaky. This error happened on 
> > windows but I have also seen it happen on solaris 10.  Has anyone else seen 
> > this? If it is due to network flakiness then perhaps svn should retry to 
> > work around this transparently, and thus be more robust? Perhaps it could 
> > retry up to 3 times with a sleep a 1 second between retries?
>
> Is your working copy on a network filesystem (CIFS, NFS, ...)?
[snip]
While working copies on networks filesystems should generally work, such use is 
strongly discouraged.
[snip]
No. There is no network filesystem (CIFS) here. What about when I am using 
solaris? That's proof that it cannot be due to CIFS. The internet is being used 
because that it is where the timestamp server is. When the code tries to call 
out to that timeserver it has to travel via the corporate network, including 
navigating via the internet proxy. This network call fails randomly due a flaky 
network.

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. FIS is a trading name of the following 
companies: Fidelity Information Services Ltd (registered in England 
No.02225203), FIS Payments (UK) Ltd (No.04215488), FIS Asiapacrim Holdings Ltd 
(No.06707320), Certegy Card Services Ltd (No.03517639) and Efunds International 
Ltd (No.01930117), all with their registered office at Floor 1, 51/53 Hagley 
Road, Birmingham B16 8TU, United Kingdom; and FIS Payments (Ireland) Ltd 
(registered in Ireland No.126879), with its registered office at 25/28 North 
Wall Quay, Dublin 1, D01 H104, Ireland. FIS Payments (UK) Ltd is authorised and 
regulated by the Financial Conduct Authority; some services are covered by the 
Financial Ombudsman Service (in the UK). Calls to and from the companies may be 
recorded for quality purposes. All of the above companies are part of FIS 
(Fidelity National Information Services Inc.).

RE: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network

[Marlow, Andrew]

Sorry everyone, I mis-spoke below. While looking at this issue I was also 
filing a bug report on the maven jar signing plugin, which also has a problem 
when the network is flaky. That is the thing that was calling out to the 
timestamp server, not svn. I got mixed up, sorry.

Regarding the comment that was made, I don't know exactly how the svn repo is 
hosted in the corporate environment I am in. It is accessed via an http URL 
(not https, I know). The underlying filesystem is Windows because every now and 
then we get aggro due to the case preserving behaviour of the Windows 
filesystem. But is it on a network share? Not sure, but I don't think so. IMO 
that would be an extremely bad setup.

-Original Message-
From: Marlow, Andrew 
Sent: 24 April 2019 09:52
To: users@subversion.apache.org
Subject: RE: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of 
flaky network

Reply below:

-Original Message-
From: Stefan Sperling 
Sent: 24 April 2019 07:54
To: Marlow, Andrew 
Cc: Johan Corveleyn ; users@subversion.apache.org
Subject: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky 
network

On Wed, Apr 24, 2019 at 12:55:47AM +0200, Johan Corveleyn wrote:
> On Mon, Apr 22, 2019 at 9:22 AM Marlow, Andrew
>  wrote:
> > Hello everyone,
> > I got this error below during an svn co command. It left my workspace in a 
> > bad state from which I had to do svn cleanup before trying again (the retry 
> > worked):
[snip]
> > I think this happens when the network is flaky. This error happened on 
> > windows but I have also seen it happen on solaris 10.  Has anyone else seen 
> > this? If it is due to network flakiness then perhaps svn should retry to 
> > work around this transparently, and thus be more robust? Perhaps it could 
> > retry up to 3 times with a sleep a 1 second between retries?
>
> Is your working copy on a network filesystem (CIFS, NFS, ...)?
[snip]
While working copies on networks filesystems should generally work, such use is 
strongly discouraged.
[snip]
No. There is no network filesystem (CIFS) here. What about when I am using 
solaris? That's proof that it cannot be due to CIFS. The internet is being used 
because that it is where the timestamp server is. When the code tries to call 
out to that timeserver it has to travel via the corporate network, including 
navigating via the internet proxy. This network call fails randomly due a flaky 
network.

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. FIS is a trading name of the following 
companies: Fidelity Information Services Ltd (registered in England 
No.02225203), FIS Payments (UK) Ltd (No.04215488), FIS Asiapacrim Holdings Ltd 
(No.06707320), Certegy Card Services Ltd (No.03517639) and Efunds International 
Ltd (No.01930117), all with their registered office at Floor 1, 51/53 Hagley 
Road, Birmingham B16 8TU, United Kingdom; and FIS Payments (Ireland) Ltd 
(registered in Ireland No.126879), with its registered office at 25/28 North 
Wall Quay, Dublin 1, D01 H104, Ireland. FIS Payments (UK) Ltd is authorised and 
regulated by the Financial Conduct Authority; some services are covered by the 
Financial Ombudsman Service (in the UK). Calls to and from the companies may be 
recorded for quality purposes. All of the above companies are part of FIS 
(Fidelity National Information Services Inc.).
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. FIS is a trading name of the following 
companies: Fidelity Information Services Ltd (registered in England 
No.02225203), FIS Payments (UK) Ltd (No.04215488), FIS Asiapacrim Holdings Ltd 
(No.06707320), Certegy Card Services Ltd (No.03517639) and Efunds International 
Ltd (No.01930117), all with their registered office at Floor 1, 51/53 Hagley 
Road, Birmingham B16 8TU, United Kingdom; and FIS Payments (Ireland) Ltd 
(registered in Ireland No.126879), with its registered office at 25/28 North 
Wall Quay, Dublin 1, D01 H104, Ireland. FIS Payments (UK) Ltd is authorised and 
regulated by the Financial Conduct Authority; some services are covered by the 
Financial Ombudsman Service (in the UK). Calls to and from the companies may be 
rec

RE: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network

[Marlow, Andrew]

Reply below:

-Original Message-
From: Johan Corveleyn 
Sent: 24 April 2019 11:30
To: Marlow, Andrew 
Cc: users@subversion.apache.org
Subject: Re: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of 
flaky network

> >Regarding the comment that was made, I don't know exactly how the svn repo 
> >is hosted in the corporate environment I am in. It is accessed via an http 
> >URL (not https, I know). The underlying filesystem is Windows because every 
> >now and then we get aggro due to the case preserving behaviour of the 
> >Windows filesystem. But is it on a network share? Not sure, but I don't 
> >think so. IMO that would be an extremely bad setup.

>>The network share Stefan and I are referring to is not on the server side 
>>(which is accessed via https, that's fine; and
>> we're not concerned with how that server is set up). We're talking about the 
>> client-side location where you're putting your working copy.
[snip]
Yes, thanks for clearing that point up.

> Where are you checking out your software? Is it on a local disk?
Yes.

>Or on a CIFS mounted filesystem (Windows)
No.

> or on an NFS-mounted filesystem, or SMB, ... if you're on Solaris?
No.

> If in step 2 you're indeed using some network share as the location for your 
> working copy, that could be problematic.
Indeed, especially with the network I am using.

> As Stefan said, this is discouraged, and you should try to put working copies 
> on local disks.
Good job I'm not, then. 😊


--
Johan
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. FIS is a trading name of the following 
companies: Fidelity Information Services Ltd (registered in England 
No.02225203), FIS Payments (UK) Ltd (No.04215488), FIS Asiapacrim Holdings Ltd 
(No.06707320), Certegy Card Services Ltd (No.03517639) and Efunds International 
Ltd (No.01930117), all with their registered office at Floor 1, 51/53 Hagley 
Road, Birmingham B16 8TU, United Kingdom; and FIS Payments (Ireland) Ltd 
(registered in Ireland No.126879), with its registered office at 25/28 North 
Wall Quay, Dublin 1, D01 H104, Ireland. FIS Payments (UK) Ltd is authorised and 
regulated by the Financial Conduct Authority; some services are covered by the 
Financial Ombudsman Service (in the UK). Calls to and from the companies may be 
recorded for quality purposes. All of the above companies are part of FIS 
(Fidelity National Information Services Inc.).

RE: EXTERNAL: which review tools are suitable for codes versioned by svn

[Marlow, Andrew]

Crucible.

-Original Message-
From: wuzhouhui 
Sent: 11 August 2019 05:19
To: Subversion 
Subject: EXTERNAL: which review tools are suitable for codes versioned by svn

Hi,

I'm searching some review tools which are suitable for codes versioned by 
Subversion, any recommends?

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. FIS is a trading name of the following 
companies: Advanced Portfolio Technologies Ltd (No: 6312142) | Clear2Pay 
Limited (No: 5792457) | Decalog (UK) Limited (No: 2567370) | FIS Apex 
(International) Limited (No: 260) | FIS Apex (UK) Limited (No. 3573008) | 
FIS Consulting Services (UK) Limited (No: 2486794) | FIS Derivatives Utility 
Services (UK) Limited (No: 9398140) | FIS Energy Solutions Limited (No: 
1889028) | FIS Global Execution Services Limited (No. 3127109) | FIS Global 
Trading (UK) Limited (No: 2523114) | FIS Investment Systems (UK) Limited (No: 
1366010) | FIS Sherwood Systems Group Limited (No: 982833) | FIS Systems 
Limited (No: 1937159) | FIS Treasury Systems (Europe) Limited (No: 2624209) | 
FIS Treasury Systems (UK) Limited (No: 2893376) | GL Settle Limited (No: 
2396127) | Integrity Treasury Solutions Europe Limited (No: 3289271) | Monis 
Software Limited (No: 2333925) | Reech Capital Limited (No: 3649490) | 
Solutions Plus Consulting Services Limited (No: 3839487) | Valuelink 
Information Services Limited (No: 3827424) all registered in England & Wales 
with their registered office at 25 Canada Square, London E14 5LQ | FIS Global 
Execution Services Limited is authorised and regulated by the Financial Conduct 
Authority | Certegy Card Services Limited (No: 3517639) | Certegy France 
Limited (No: 2557650) | eFunds International Limited (No: 1930117) | Fidelity 
Information Services Limited (No: 2225203) | FIS Payments (UK) Limited (No: 
4215488) | Metavante Technologies Limited (No: 2659326) all registered in 
England & Wales with their registered office at 1st Floor Tricorn House, 51-53 
Hagley Road, Edgbaston, Birmingham, West Midlands, B16 8TU, United Kingdom | 
FIS Payments (UK) Limited is authorised and regulated by the Financial Conduct 
Authority; some services are covered by the Financial Ombudsman Service (in the 
UK). Clear2Pay Limited, Registered in Scotland (No SC157659), Registered 
Office: Clear2Pay House, Pitreavie Court, Pitreavie Business Park Queensferry 
Rd, Dunfermline, Fife, SS, KY11 8UU, Scotland | FIS eProcess Intelligence LLC 
(UK Branch), UK Establishment Registered in England & Wales (No: FC16527/Branch 
No. BR000355), Registered Branch Office: 25 Canada Square, London, E14 5LQ; FIS 
eProcess Intelligence LLC is a limited liability company formed in the USA 
registered on file with the Office of the Delaware Secretary of State, Division 
of Corporations (File No. 2032143), Head Office: 601 Riverside Avenue, 
Jacksonville Florida, FL32204, USA | FIS Investment Systems LLC, UK 
Establishment Registered in England & Wales (No: FC033836/Branch No. BR018923), 
Registered Branch Office: 25 Canada Square, London, E14 5LQ; FIS Investment 
Systems LLC is a limited liability company formed in the USA registered on file 
with the Office of the Delaware Secretary of State, Division of Corporations 
(File No. 0881255), Head Office: 377 E. Butterfield Road, Suite 800, Lombard, 
IL 60148, USA | Calls to and from the companies may be recorded for quality 
purposes. | All of the named companies are part of FIS (Fidelity National 
Information Services, Inc.).

RE: EXTERNAL: error 'Network connection closed unexpectedly' while svn update

[Marlow, Andrew]

Hello everyone and thank you Detlef for reporting this situation. I want to add 
that I also see this from time to time and would like to see a fix.

It is very easy for me to see network errors from subversion because I am in an 
environment where the network is extremely unreliable. This fact has revealed 
several software products that, IMHO, do not take transient network errors into 
account. I think it is a common failing, especially as networks have generally 
become more reliable over the years (so it’s easy to take it for granted when 
writing socket code).

From: Detlef Braungardt 
Sent: 05 December 2019 15:58
To: users@subversion.apache.org
Subject: EXTERNAL: error 'Network connection closed unexpectedly' while svn 
update

Hi everyone,


we use TortoiseSVN for our development.

But in a special situation we get an error 'Network connection closed 
unexpectedly' during a svn update. The steps to reproduce the situation is 
writed down in the Google Groups thread.
I posted this error as a bug on the Tortoise list.
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/tortoisesvn/MSaacoX73DU
After a short communication we found out that the bug is probably contained in 
the libsvn.
C:\Program Files\TortoiseSVN\bin>svn update "D:\Develop\FIRMA\trunk\Tests" -r 
15749
Updating 'D:\Develop\FIRMA\trunk\Tests':

svn: E235000: In file 
'/build/subversion-Lv3Qkk/subversion-1.9.7/subversion/libsvn_fs_base/trail.c' 
line 97: assertion failed (! bfd->in_txn_trail)
svn: E210002: Network connection closed unexpectedly
Can you help us to fix this bug?
Thanks in advance.


Best regards

Detlef


--

*

*  Computerservice Braungardt   *

*

*  Dipl.-Wirtsch.-Inf.  Detlef Braungardt   *

*

* email:deve...@coseb.de   
 *

* www:  
www.CoseB.de
*

*

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. FIS is a trading name of the following 
companies: Advanced Portfolio Technologies Ltd (No: 6312142) | Clear2Pay 
Limited (No: 5792457) | Decalog (UK) Limited (No: 2567370) | FIS Apex 
(International) Limited (No: 260) | FIS Apex (UK) Limited (No. 3573008) | 
FIS Consulting Services (UK) Limited (No: 2486794) | FIS Derivatives Utility 
Services (UK) Limited (No: 9398140) | FIS Energy Solutions Limited (No: 
1889028) | FIS Global Execution Services Limited (No. 3127109) | FIS Global 
Trading (UK) Limited (No: 2523114) | FIS Investment Systems (UK) Limited (No: 
1366010) | FIS Sherwood Systems Group Limited (No: 982833) | FIS Systems 
Limited (No: 1937159) | FIS Treasury Systems (Europe) Limited (No: 2624209) | 
FIS Treasury Systems (UK) Limited (No: 2893376) | GL Settle Limited (No: 
2396127) | Integrity Treasury Solutions Europe Limited (No: 3289271) | Monis 
Software Limited (No: 2333925) | Reech Capital Limited (No: 3649490) | 
Solutions Plus Consulting Services Limited (No: 3839487) | Valuelink 
Information Services Limited (No: 3827424) all registered in England & Wales 
with their registered office at 25 Canada Square, London E14 5LQ | FIS Global 
Execution Services Limited is authorised and regulated by the Financial Conduct 
Authority | Certegy Card Services Limited (No: 3517639) | Certegy France 
Limited (No: 2557650) | eFunds International Limited (No: 1930117) | Fidelity 
Information Services Limited (No: 2225203) | FIS Payments (UK) Limited (No: 
4215488) | Metavante Technologies Limited (No: 2659326) all registered in 
England & Wales with their registered office at 1st Floor Tricorn House, 51-53 
Hagley Road, Edgbaston, Birmingham, West Midlands, B16 8TU, United Kingdom | 
FIS Payments (UK) Limited is authori

RE: EXTERNAL: Who else is using SVN for large-binary-asset storage?

[Marlow, Andrew]

Hello everyone,

The answer is "yes". I have come across investment banks that store boost 
releases in subversion. Sometimes it's a full boost release and that can be 
quite large. They take a long time to checkout but at the time it seemed better 
than the alternatives available at the time, e.g. placing the artifacts on an 
SFTP site or Windows share (ugh).

-Original Message-
From: Karl Fogel 
Sent: 24 April 2020 17:40
To: Subversion Users 
Subject: EXTERNAL: Who else is using SVN for large-binary-asset storage?

Are there other companies out there using SVN for large-binary-blob storage?

I'm wondering if it might be possible to put together a mini-consortium of 
companies to fund the completion of Issue #525:

  
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FSVN-525&data=02%7C01%7CAndrew.Marlow%40fisglobal.com%7C6729a1c6e8434e58ae4b08d7e86e7f0d%7Ce3ff91d834c84b15a0b418910a6ac575%7C0%7C0%7C637233433584704974&sdata=WDAoL3RF5rOb0nx7Ig1wFIZkrisKSw%2BgKC1nGZ2GaPM%3D&reserved=0
  "allow working copies without text-base/"

Our company keeps medium-large (say, ~5GB) binary blobs under version control 
in a dedicated Subversion repository, and it works quite well.  Subversion can 
handle files of that size just fine, and it enables us to do path-based 
authorization (yay) and partial-tree checkouts. [1]

But the presence of text-base files in .svn/pristine/ is a real downer :-).  
The text-base files are mostly pointless in this case, and they double the 
client-side disk space usage.

There is no useful diff between two revisions of these binary blobs: there's no 
human-readable diff *and* there's rarely any machine-useable diff either (e.g., 
for reducing network time when receiving an update or committing a new 
revision).  So the only benefit from the text-base files is to make 'svn 
revert' faster.  We'd be happy to have 'svn revert' re-fetch the file from the 
repository if it meant we could reduce our storage cost on the client side by 
half.

(Plus you'd only lose local-revert capability on files where you know you don't 
need it, since presumably the no-text-base behavior would be optional per file 
and controlled via an 'svn:no-pristine' property or something like that.)

Is anyone else in a similar situation?  If we join forces, we could probably 
fund one or more Subversion developers to finally get Issue #525 done.  I'd be 
happy to do the organizing (I'm still reasonably familiar with Subversion 
development and who does what, though I haven't been an active developer in the 
project in many years).

Please CC me on any replies, as I'm not subscribed to users@.

Best regards,
-Karl

[1] We investigated using Git too, but, though Git good for many things, it is 
not well-suited for this particular job.  The Git Large-File Storage extension 
(https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit-lfs.github.com%2F&data=02%7C01%7CAndrew.Marlow%40fisglobal.com%7C6729a1c6e8434e58ae4b08d7e86e7f0d%7Ce3ff91d834c84b15a0b418910a6ac575%7C0%7C0%7C637233433584714968&sdata=XLfHamWk4don%2F1w77lC8zcC85ORUS%2FCnkuB8ft53XGs%3D&reserved=0)
 doesn't address most of our needs either; it's solving a different problem, I 
guess.
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. FIS is a trading name of the following 
companies: Advanced Portfolio Technologies Ltd (No: 6312142) | Clear2Pay 
Limited (No: 5792457) | Decalog (UK) Limited (No: 2567370) | FIS Apex 
(International) Limited (No: 260) | FIS Apex (UK) Limited (No. 3573008) | 
FIS Consulting Services (UK) Limited (No: 2486794) | FIS Derivatives Utility 
Services (UK) Limited (No: 9398140) | FIS Energy Solutions Limited (No: 
1889028) | FIS Global Execution Services Limited (No. 3127109) | FIS Global 
Trading (UK) Limited (No: 2523114) | FIS Investment Systems (UK) Limited (No: 
1366010) | FIS Sherwood Systems Group Limited (No: 982833) | FIS Systems 
Limited (No: 1937159) | FIS Treasury Systems (Europe) Limited (No: 2624209) | 
FIS Treasury Systems (UK) Limited (No: 2893376) | GL Settle Limited (No: 
2396127) | Integrity Treasury Solutions Europe Limited (No: 3289271) | Monis 
Software Limited (No: 2333925) | Reech Capital Limited (No: 3649490) | 
Solutions Plus Consulting Services Limited (No: 3839487) | Valuelink 
Information Services Limited (No: 3827424) all registered in England & Wales 
with their registered office at 25 Canada Square, London E14 5LQ | FIS Global 
Execution Services Limited is authorised and regulated by the Financial Conduct 
Authority | Certegy Card Services Limited (No: 3517639) | Cer

RE: Unable to Check Out SVN Folders

[Marlow, Andrew]

I too have seen this error several times and I am convinced it happens in the 
presence of an unreliable network. The network I am using is very unreliable so 
this problem is seen from time to time. When it happens the checkout has to be 
cleaned, then if the command is tries again it usually works.

From: Nathan Hartman 
Sent: 18 May 2022 01:52
To: Cameron Hagen 
Cc: users@subversion.apache.org
Subject: Re: Unable to Check Out SVN Folders

On Tue, May 17, 2022 at 7:52 PM Cameron Hagen 
mailto:cha...@appareo.com>> wrote:
Hello there,

I'd like to check out a number of SVN folders, but with each one I run into an 
error where after checking out a few documents, it stalls, and then gives me 
this error:

Checkout Failed!

Error: Error running context: An existing connection was forcibly closed by the 
remote host

When I delete the folder and give it another try, sometimes it will get through 
more documents, sometimes it gets through less, but it never actually finishes. 
I have tried using different internet connections, but get consistent errors.

Very new to Subversion Edge and would really appreciate any feedback.
Thanks,
Cam

NOTICE: This message {including attachments} is covered by the Electronic 
Communication Privacy Act, 18 U.S.C. sections 2510-2521, is CONFIDENTIAL and 
may also be protected by ATTORNEY-CLIENT OR OTHER PRIVILEGE. If you believe 
that it has been sent to you in error, do not read it. If you are not the 
intended recipient, you are hereby notified that any retention, dissemination, 
distribution, or copying of this communication is strictly prohibited. Please 
reply to the sender that you have received the message in error and then delete 
it.

Hello,

We've had various reports with this error message over the years. The cause is 
usually a server side or network issue, but there doesn't seem to be a common 
theme of one particular cause. Causes have ranged from anything from antivirus 
software to network configurations to firewalls to old versions of SVN on the 
server. If you search for the exact text of the error message in our mailing 
list archives (see [1], you'll find  discussions and (hopefully) what fixed it 
for different people. There's also the StackOverflow question at [2].

You mentioned that you are using Subversion Edge. Do you know whether the 
version of  Subversion Edge on the repository server is the latest available?

>From your screenshot it appears you are using TortoiseSVN on the client (your 
>computer). What version of TortoiseSVN are you using?

Also do you know whether you're going through a proxy?

Is the repository server on the same LAN as your client computer, or across a 
VPN, or...?

When you say it stalls, is there a noticeable delay? Approximately how long 
(seconds? minutes?)

Cheers,
Nathan

[1] SVN mailing list archives:
https://subversion.apache.org/mailing-lists.html
 -- see under Archives for users@

[2] StackOverflow question about this error:
https://stackoverflow.com/questions/22965847/svn-error-running-context-an-existing-connection-was-forcibly-closed-by-the-rem


The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. FIS is a trading name of the following 
companies: Advanced Portfolio Technologies Ltd (No: 6312142) | Alphakinetic 
Limited (No: 06897969) | Clear2Pay Limited (No: 5792457) | eFunds International 
Limited (No: 1930117) | Fidelity Information Services Limited (No: 2225203) | 
FIS Derivatives Utility Services (UK) Limited (No: 9398140) | FIS Energy 
Solutions Limited (No: 1889028) | FIS Global Execution Services Limited (No. 
3127109) | FIS Capital Markets UK Limited (No: 982833) | Integrity Treasury 
Solutions Europe Limited (No: 3289

RE: Keyword substitutions not being merged correctly

[Andrew Reedick]

> From: David Sandberg [mailto:david.sandb...@hickorytech.com]
> Sent: Wednesday, March 20, 2013 1:18 PM
> 
> 1) User Jim commits a new file A with the Revision keyword to the trunk
> in revision 101.
> 2) User Sam merges trunk revision 101 into his feature branch, and the
> new file A comes across fine and shows revision 101 in the keyword
> substitution part of the file.
> 3) Jim commits an update to file A to the trunk, in revision 200.  (If
> other users who are working in the trunk pull this file at this time,
> it updates and the keyword in their updated file correctly reads 200.)
> 4) Now, Sam merges trunk revision 200 into his feature branch.  The
> merge happens automatically without prompts for conflicts or anything,
> and the resulting file A contains MOST of the changes from the trunk
> revision ... EXCEPT for the Revision keyword, which stays at 101!

As Thorsten pointed out, the keywords do not store the actual revision number.  
Only the unexpanded "$Rev$" is stored on the server.

Its sounds like "svn:keywords" isn't set correctly on Sam's feature branch.  
Whenever a new revision of a file is created (such as after a merge) the 
revision keyword should match the "Last Changed Rev:" (which you can see when 
you run "svn info" on the file.)  What does Sam see when he runs "svn info" in 
step 4?  

After Sam's merge in step 4 (and before Sam's commit,) does a "svn diff" show 
any differences in the file?  If the merge didn't actually change anything, 
then the file won't change, so the "Last Changed Rev:" doesn't change, so the 
revision keyword doesn't change.

Also, you won't see the revision keyword change in the file until after you do 
a commit.

RE: Keyword substitutions not being merged correctly

[Andrew Reedick]

> -Original Message-
> From: David Sandberg [mailto:david.sandb...@hickorytech.com]
> Sent: Wednesday, March 20, 2013 2:52 PM
> 
> Thank you for that crystal clear explanation, which accounts perfectly
> for the observed behavior.  I will add that I am not sure I agree with
> the correctness of that behavior, but that's only because it doesn't
> happen to fit our operational model, in which we cherry-pick revisions
> from the trunk into our release branch and then build archives for
> deployment to customers.  The problem is that the resulting deployed
> files need to reflect the revision numbers that were committed into the
> trunk ... or at least some newer revision number than in previous
> builds. From what you've described, we could perhaps achieve that by
> committing the merged set of files to our release branch before we
> begin a build, but that seems like a backwards way to go about things
> when we may find ourselves still needing to make updates as part of
> completing the build, so we would be committing potentially broken
> revisions in order to get these keyword substitutions to update before
> the build process runs.


That's why we grab the 'Last Changed Rev:" of the root directory of the release 
tree and use that as the release number.  The root revision is guaranteed to 
change if there's a change anywhere in its subtree.

In my experience, trying to manipulate meta-data inside of the files is just 
not worth the effort except in one-off script files.  Meaning, why are you 
storing information *about* the file *inside* of the file?  (And even in the 
case of one-off files, I'm more interested in the svn URL than the actual 
revision number.)

IMO, you would skip a lot of angst if you just update the keywords during your 
release packaging process, i.e. have your build/packaging script walk the files 
and update the "keywords" manually.  Even so, keywords don't really provide 
much value, in that they don't tell you what the correct revision should be 
(i.e. is the correct release installed?) nor do they reveal file tampering 
(i.e. production changes.)  IMO, you need to adopt a proper installer script 
and create an audit script.  (Gnu tar has a --diff option, which gives you 
quick and dirty packaging, deployment, and auditing functionality.)  Once you 
have those in place, the "need" for revision keywords goes away.

windows binaries with xampp

[Andrew Peterson]

Has anyone successfully used xampp with the binaries from:
Win32Svn <http://sourceforge.net/projects/win32svn/> (32-bit client, server
and bindings, MSI and ZIPs; maintained by David Darj <http://alagazam.net/>)


I've tried a bunch of different configurations, but every time I tried to
load the mod_dav_svn.so and the mod_authz_svn.so, apache just crashes and
tells me it can't load the module.

Thanks,

Andrew

Version 1.7.12 - "conflict_action" issue when running Update

[Andrew Newlands]

Hi,

We have searched mailing list archives but it is difficult to find any matches 
for this problem.

Can you please advise on the following, which was generated by TSVN during an 
update operation, initiated from the Windows Explorer context menu, with TSVN 
1.7.12, 32-bit, under Windows 7 (with latest win updates applied)

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

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

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


This is not much else we can tell you at this stage.  The UI, shows this...

Command: Update
Updating: C:\DATA Britannic\Development - .NET\netPCI
Error: In file
Error:  
'D:\Development\SVN\Releases\TortoiseSVN-1.7.12\ext\subversion\subversion\libsvn_wc\update_editor.c'
Error:  line 1587: assertion failed (action == svn_wc_conflict_action_edit || 
action
Error:  == svn_wc_conflict_action_delete || action == 
svn_wc_conflict_action_replace)
Completed!:


Andrew Newlands
Software & Consultancy Services Manager

Britannic Technologies Ltd
t: +44 1483 242531
anewla...@btlnet.co.uk<mailto:anewla...@btlnet.co.uk>
www.btlnet.co.uk<http://www.btlnet.co.uk>
[http://www.btlnet.co.uk/images/nlinkedin.jpg]<http://www.linkedin.com/company/britannic-technologies/products>[http://www.btlnet.co.uk/images/ntwitter.jpg]<http://www.twitter.com/BritannicTech>[http://www.btlnet.co.uk/images/nfacebook.jpg]<http://www.facebook.com/pages/Britannic-Technologies/202957249732198>[http://btlnet.co.uk/images/nYouTube.jpg]<http://www.youtube.com/user/BritannicTech>

[http://www.btlnet.co.uk/britannic_logo2.jpg]<http://www.btlnet.co.uk/>

Watch the Telegraph Business Club video about Britannic at our educational TV 
site - britannictech.tv<http://britannictech.tv>

This email and any files transmitted with it are confidential and intended for 
the addressee only. If you are not the intended recipient please notify the 
sender and delete this email. The views expressed in this email are personal, 
and do not constitute a commitment by Britannic Technologies Ltd unless 
specified by a separate, written agreement.

Registered Office: Britannic House, Merrow Business Park, Guildford, Surrey GU4 
7WA. Registered in England no. 2090797.



<><><><><>

"svn log --xml --use-merge-history ..." doesn't include --use-merge-history in the xml output?

[Andrew Reedick]

Is it just me or is svn log's "--xml" switch not including 
"--use-merge-history" information?

The text output of "svn log --use-merge-history" includes the "Merged via: 
r3673" information:

r3584 | bob | 2013-04-16 15:50:48 -0400 (Tue, 16 Apr 2013) | 1 line
Merged via: r3673

Fixed flux capacitor


whereas "svn log --xml --use-merge-history" provides no "Merged via: ..." 
information:

bob 
2013-04-16T19:50:48.762112Z

/project/branches/1.1/source/foo.jcl

Fixed flux capacitor



This is with the svn CLI client, version 1.7.9 (r1462340)

RE: "svn log --xml --use-merge-history ..." doesn't include --use-merge-history in the xml output?

[Andrew Reedick]

> -Original Message-
> From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] 
> Sent: Wednesday, May 01, 2013 4:24 PM
> To: users@subversion.apache.org
> Subject: "svn log --xml --use-merge-history ..." doesn't include 
> --use-merge-history in the xml output?
>
> Is it just me or is svn log's "--xml" switch not including 
> "--use-merge-history" information?
>
> The text output of "svn log --use-merge-history" includes the "Merged via: 
> r3673" information:
> 
> r3584 | bob | 2013-04-16 15:50:48 -0400 (Tue, 16 Apr 2013) | 1 line
> Merged via: r3673
> 
> Fixed flux capacitor
> 
>
> whereas "svn log --xml --use-merge-history" provides no "Merged via: ..." 
> information:
> revision="3584">
> bob 
> 2013-04-16T19:50:48.762112Z
> 
> kind="file"
>action="M">/project/branches/1.1/source/foo.jcl
> 
> Fixed flux capacitor
> 


Bah, never mind.  In the xml, the entries for the merged revisions are 
sub-nodes of the logentry, e.g. 


bob_porter
2013-05-01T18:43:40.613101Z
comment

bob_slydell
2013-05-01T17:53:15.616621Z
stock option equity sharing program


...

RE: mergeinfo between svn copied branches and merges

[Andrew Reedick]

> From: Z W [mailto:mpc8...@gmail.com] 
> Sent: Tuesday, May 07, 2013 11:53 AM
> To: users@subversion.apache.org
> Subject: mergeinfo between svn copied branches and merges
>
> we have branchA
> we svn copy branchA to produce branchB
> branches A and B continues development and checkins
> branchA is merged to branch B continuously
> branchA finishes, tagged
> we then svn copy branchA to produce branchC
> we like to continue branchC merging to branchB
> we hear u clearly that the merge info are copied between branches
> we performed svn mergeinfo merged on branchB working copy
> with branchA
> we could see the correct list of merged rev numbers
> we performed svn mergeinfo eligible on branchB working copy with branch A; we 
> see correct list of eligigle rev numbers
> we learn that these numbers are used by SVN to calculate what needs to be 
> merged from branchB to branchA (-reintegrate)
> we performed svn mergeinfo merged on branchB working copy with branchC
> we see a new list (not including list of merged rev numbers from branchA)


> we learn that if we reintegrate from branchB to branchC, because those list 
> of merged rev numbers from branchA are not there, SVN would not know those 
> rev numbers changes already exist in branchC
> so SVN would try to reintegrate those list of merged rev numbers from branchA 
> on branchC
> thus causing tree conflict.

Svn will implicitly know about the rev numbers from branchA because branchA is 
a subset of branchC.  Go here 
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.nomergedata
 and read "Natural History and Implicit Mergeinfo".

In this case, all you should have to do is:
a) merge branchC UP to branchB
b) merge --reintegrate branchB DOWN to branchC.
Step a) will pick up any branchA changes (because all of branchA is a subset of 
branchC.)

If you did additional work on branchA *after* creating branchC, then you would 
need to:
a) merge branchA UP to branchB,
b) merge branchC UP to branchB,
c) merge --reintegrate branchB down to branchC.

RE: mergeinfo between svn copied branches and merges

[Andrew Reedick]

> From: Z W [mailto:mpc8...@gmail.com] 
> Sent: Wednesday, May 08, 2013 6:49 AM
> To: Andrew Reedick
> Cc: users@subversion.apache.org
> Subject: Re: mergeinfo between svn copied branches and merges
>
> In this case, all you should have to do is:
> a) merge branchC UP to branchB
> b) merge --reintegrate branchB DOWN to branchC.
> Step a) will pick up any branchA changes (because all of branchA is a subset 
> of branchC.)
>
> >> This strategy is still new to us.
> We're not sure what the intermediate steps are trying to accomplish, esp the 
> merge up and down parts.
> What is the exact syntax (as an example) for (a) and (b) ?

a) merge branchC UP to branchB
cd branchB_workspace (or create a brand new, clean workspace)
svn status (check for existing changes)
svn update (If your workspace is not up to date, svn merge will 
complain.)
svn merge svn://.../branchC
resolve any conflicts
svn ci

b) merge --reintegrate branchB DOWN to branchC.
cd branchC_workspace (or checkout a clean workspace)
svn status
svn update
Notify folks to not check into branchB, or simply lock branchB (since 
we will need to delete branchB)
svn merge --reintegrate svn://.../branchB
resolve any conflicts
svn ci 
svn log -l 3 svn://.../branchB (Since we're going to delete branchB, 
make sure that no one checked into branchB after your merge)
svn rm svn://.../branchB
svn copy svn://.../branchC@1234 svn://.../branchB  (recreate the 
branchB if it is still needed.)
where 1234 is either the HEAD of branchC or the merge point on 
branchC.  It's up to you.

This is covered in the svn book:  
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

UP/DOWN:
You merge UP to a child branch that was created from a parent branch.  You 
merge "back DOWN" to a parent branch from a child branch.  "UP" and "DOWN" are 
just semantics to help you keep things straight due to the need to run 
--reintegrate.  Once svn 1.8 comes out, you shouldn't have to worry about up, 
down, and --reintegrate anymore.

>> we svn copy branchA to produce branchB
In this case, branchA is the parent, and branchB is the child, so you merge UP 
from A to B, and DOWN (via --reintegrate) from B back to A.  In the example 
given in the svn book, branchA would be the "calc-trunk" and branchB would be 
"my-calc-branch".

>> we then svn copy branchA to produce branchC
Since branchC was created from branchA, branchC would still be the "parent" of 
branchB.  Merge UP to branchB, merge DOWN to branchC.


Of course, this is Subversion, and merge tracking wasn't part of the original 
design specs, so there's always the chance of something odd happening...

Branching and merging:  http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html

RE: svn issue

[Andrew Reedick]

You can do a fresh checkout and not include project10 in the initial update:
svn co -N svn://.../top_dir
cd top_dir
cd svn update project1 project2 ... project 9
Future 'svn update' commands in the top_dir directory will only update projects 
1 through 9.

Or you can explicitly not update project 10:
Windows CMD shell:
for /f %i in (' svn ls ^| findstr /v project10') do @svn update %i

ksh/bash:
svn ls | grep -v project 10 | xargs svn update


Disclaimer:  Top posting because Outlook has crushed my spirit.



From: Amit Kumar [IN7537] [mailto:amit_ku...@mindtree.com]
Sent: Wednesday, May 08, 2013 3:26 AM
To: users@subversion.apache.org
Cc: amitsinghra...@gmail.com
Subject: svn issue

Hi,

I found an issue in SVN. Suppose there are 10 project is in directory. And I 
want to update only 9 project. There is no option to lock one project not to 
update.
By this issue I get problem. I will request you to solve this issue.

Thanks & Regards,
Amit kumar | Senior Software Engineer | P +91 80 670 60718 | M +91 9740012743 | 
www.mindtree.com
MindTree Limited | West Campus, Global Village, RVCE Post, Mysore Road, 
Bangalore, India - 560 059 | Welcome to possible




http://www.mindtree.com/email/disclaimer.html

RE: How to remove revision number in mergeinfo eligible list

[Andrew Reedick]

> From: Z W [mailto:mpc8...@gmail.com] 
> Sent: Wednesday, May 08, 2013 3:05 PM
> To: users@subversion.apache.org
> Subject: How to remove revision number in mergeinfo eligible list
>
> Hi All 
>
> We use SVN 1.6
>
> We have a revision number which refuses to move to the merged list after 
> applying a merge.
>
> [root@host branchWC]# svn mergeinfo --show-revs eligible 
> https://some.url.com/svn/root/trunk
> r6554
>
> [root@host branchWC]# svn merge -c 6554 --record-only 
> https://some.url.com/svn/root/trunk
> [root@host branchWC]# svn propget svn:mergeinfo .
>
> It returns empty.
>
> How do we remove revision number in mergeinfo eligible list or force it to 
> move to the merged list ?
> We cannot use regular merge for this rev number, unfortunately.
>
> Any help is appreciated.
> Sincerely

That's odd.

Compare the pre-merge svn:mergeinfo with the post-merge copy to see if anything 
was changed:
svn propget svn:mergeinfo https://.../root/trunk > a.txt
svn propget svn:mergeinfo . > b.txt
diff a.txt b.txt

If you run mergeinfo again (after the merge), does 6554 still show up in the 
list?
svn mergeinfo ... | grep 6554   

Do you see a trailing asterisk (*) for the branch in svn:mergeinfo?  Ex:
/branches/1.0:3166-3179*
If so, then there might be some quirk in how svn is recording a partially 
merged range.

Is it missing from all the svn:mergeinfo properties?  (Run 'svn status' and run 
'svn propget...' on the dirs with a 'M' in the second column.)

RE: How to remove revision number in mergeinfo eligible list

[Andrew Reedick]

> From: Z W [mailto:mpc8...@gmail.com] 
> Sent: Wednesday, May 08, 2013 4:09 PM
> To: Andrew Reedick
> Cc: users@subversion.apache.org
> Subject: Re: How to remove revision number in mergeinfo eligible list
>
> Hi Andrew
>
> Thanks for responding; appreciate it.
> We followed your instruction - 
>        svn propget svn:mergeinfo https://.../root/trunk > a.txt
>        svn propget svn:mergeinfo . > b.txt
>        diff a.txt b.txt
>
> a.txt returns an empty file
> b.txt returns empty too.
>
> The revision number 6554 change is about the creation of the trunk 
> (https://.../root/trunk). In this trunk it has 2 directories A and B.
> In our working copy directory, it has directories A and B, too.
> We're trying to merge from the trunk to working copy branch
>
> svn mergeinfo ... | grep 6554 returns empty.

Okay... let's try this again.
1. checkout a clean workspace.
2. cd workspace
3. svn mergeinfo --show-revs eligible https://some.url.com/svn/root/trunk > 
pre-mergeinfo.txt
4. svn propget svn:mergeinfo . > pre-prop.txt
5. svn merge -c 6554 --record-only https://some.url.com/svn/root/trunk
6. svn propget svn:mergeinfo . > post-prop.txt
7. svn mergeinfo --show-revs eligible https://some.url.com/svn/root/trunk > 
post-mergeinfo.txt

8. diff pre-mergeinfo.txt post-mergeinfo.txt
I expect r6554 to be in pre-mergeinfo.txt and not in post-mergeinfo.txt.

9. diff pre-prop.txt post-prop.txt
If these files are different, then svn:mergeinfo was updated.

RE: How to remove revision number in mergeinfo eligible list

[Andrew Reedick]

> From: Z W [mailto:mpc8...@gmail.com] 
> Sent: Wednesday, May 08, 2013 8:25 PM
> To: Andrew Reedick
> Cc: users@subversion.apache.org
> Subject: Re: How to remove revision number in mergeinfo eligible list
>
> Hi Andrew
>
> Thanks for taking the time to respond.
> We did as told step by step and the result is the same - revision number is 
> still in eligible list at the final step
>
> [root@host newbranchWC]# svn mergeinfo --show-revs eligible 
> https://some.url.com/svn/root/trunk
> r6554
> r9946
> [root@host newbranchWC]# svn propget svn:mergeinfo .
> /root/trunk:6560,9804,9806,9836,9874-9876,9880-9881,9899-9900,9951-9952
> [root@host newbranchWC]# svn merge -c 6554 --record-only 
> https://some.url.com/svn/root/trunk
> [root@host newbranchWC]# svn propget svn:mergeinfo .
> /root/trunk:6560,9804,9806,9836,9874-9876,9880-9881,9899-9900,9951-9952
> [root@host newbranchWC]# svn mergeinfo --show-revs eligible 
> https://some.url.com/svn/root/trunk
> r6554
> r9946
>
> We wonder if it has to do with the rev number change itself.
> That 6554 rev number is about /root/Trunk creation from svn mkdir
> The following rev number 6560 is about renaming  /root/Trunk to /root/trunk
> Then the following rev number 9804 is about svn copy of dir A to 
> https://some.url.com/svn/root/trunk/A
> Then the following rev number 9806 is about svn copy of dir B to 
> https://some.url.com/svn/root/trunk/B
>
> Would such actions impact the very first rev number for folder 
> https://some.url.com/svn/root/Trunk ?
> We use SVN 1.6


The good news is that I was able to do a merge that produced output similar to 
yours.

The bad news is that you are probably merging unrelated branches...  What 
branch is your workspace set to? (svn info)  And what is the common ancestor 
between /root/Trunk and the workspace branch?  You can try 'svn merge 
--ignore-ancestry', but I don't think it will make a difference since your 
branches are probably very unrelated.

In other words, 'svn merge' should have produced some output.  The fact that it 
didn't implies that there was no merging to be done.  I have no idea why 'svn 
mergeinfo --show-rev eligible' would still list revs.

Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

Problem:  Subversion doesn't have branches.  

Subversion has directory objects, and we Humans(tm) arbitrarily decide that 
some directories are "branches," thereby giving these directories (branches) 
magical powers and mystical significance.  Meanwhile, Subversion grinds on, 
treating those magic branches as mundane directories.

You can see the effects of this problem when you change a parent directory 
common to multiple branches, e.g. changing "/projectFoo/branches" to 
"/projectBar/branches" will cause every "branch" in "/projectBar/branches/*" to 
have a shared revision.  This complicates finding branch points 
(--stop-on-copy), finding the common ancestor, etc..

Are there any plans to address this issue or otherwise make branches a first 
class object?  Or at least add a switch to 'svn log' to skip over extraneous 
"only the parent dir path changed" revisions?

Demonstration:

$ svn mkdir -m "" ^/project1/branches
Committed revision 73.
$ svn mkdir -m "" ^/project1/branches/alpha
Committed revision 74.
$ svn mkdir -m "" ^/project1/branches/beta
Committed revision 75.
$ svn log -q -v ^/project1/branches/alpha

r74 | test | 2013-05-09 15:27:49 -0400 (Thu, 09 May 2013) | 1 line
Changed paths:
   A /project1/branches/alpha

$ svn log -q -v ^/project1/branches/beta

r75 | test | 2013-05-09 15:27:50 -0400 (Thu, 09 May 2013)
Changed paths:
   A /project1/branches/beta


As you can see from the svn logs, the "alpha" and "beta" branches are 
completely independent.  They have no revisions in common.

But by renaming the parent "project1" dir to "project100", we create a linkage 
between the two:
$ svn mv -m "" ^/project1 ^/project100
Committed revision 76.
$ svn log ^/project100/branches/alpha

r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013)
Changed paths:
   D /project1
   A /project100 (from /project1:75)

r74 | test | 2013-05-09 15:27:49 -0400 (Thu, 09 May 2013)
Changed paths:
   A /project1/branches/alpha


$ svn log ^/project100/branches/beta

r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013)
Changed paths:
   D /project1
   A /project100 (from /project1:75)

r75 | test | 2013-05-09 15:27:50 -0400 (Thu, 09 May 2013)
Changed paths:
   A /project1/branches/beta


Note that the independent branches "alpha" and "beta" now have revision 76 in 
common... even though neither branch was changed.

Adding insult to injury, "svn log --stop-on-copy" will stop on revision 76, 
i.e. it treats r76 as a branch point:

$ svn log --stop-on-copy -v ^/project100/branches/alpha

r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013)
Changed paths:
   D /project1
   A /project100 (from /project1:75)

$ svn log --stop-on-copy -v ^/project100/branches/beta

r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013)
Changed paths:
   D /project1
   A /project100 (from /project1:75)


As you can see, the "independent" alpha and beta branches now have revision 76 
in common.  All because Subversion doesn't have branches.

/grumble

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: Thursday, May 09, 2013 4:35 PM
> To: users@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> 
> 
> Well, given that you have not created any branches, this works as
> expected :) There are no branch points in your repository; only
> directories. A branch is created by copying a directory (with "svn
> copy"), not by creating it (with "svn mkdir"), and that is why your --
> stop-on-copy works the way it does -- the only copy is a side effect of
> the rename (which is currently represented as copy+delete), hence --
> stop-on-copy stops ... when it sees the copy.

No, the effect is the same whether you use 'svn mkdir', 'svn copy', or 'svn 
mv', for single dirs or for trees full of files and subdirs.  If you change the 
name or path of a parent dir, you implicitly create a common revision across 
each and every subdir and file.  If you "svn mv ^/tag ^/tags" or "svn mv 
^/branches ^/project1/branches" then everything under /tags or 
/project1/branches will now have a new, common, revision according to 'svn log'.

It's not a huge problem, but in the real world (i.e. a non-contrived example) I 
have branches that have been locked and untouched for months that now have a 
new HEAD revision.  And those branches, which are supposed to be walled off 
from each other until explicitly merged, now have a revision in common.  
(*Every* file and dir in the branches and tags dir trees now has the new, 
shared rev.) 

I can understand why it happens; svn log needs to know about the parent dir 
rename in order to know (and print) the correct paths for subsequent revisions. 
 It's a mostly harmless side effect of copy/mv, but it is odd looking and seems 
sloppy from a purist point of view because something outside of the branch is 
changing the branch's history and baseline albeit in a mostly limited fashion.

Anyway, if you never restructure your high-level tags/branches/trunk dir 
structure and if you never rename a branch or tag, then you won't see this 
problem.


> The real problem here is that Subversion does not treat /renames/ as
> atomic operations. This is indeed being addressed, but a complete
> solution will take time. I'm not going to go into technical details
> here; if you're interested, you're welcome to join the dev@ list and
> listen in (or participate) in the discussions there.

Yeah, I'm aware of the rename issue (I have a background in ClearCase,) but the 
'lack of branches' is a whole issue in and of itself.  A branch really should 
be a walled off garden until you explicitly merge.

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: Friday, May 10, 2013 9:57 AM
> To: Andrew Reedick
> Cc: Branko Čibej; users@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> 
> On Fri, May 10, 2013 at 09:40:48AM -0400, Andrew Reedick wrote:
> > It's not a huge problem, but in the real world (i.e. a non-contrived
> > example) I have branches that have been locked and untouched for
> > months that now have a new HEAD revision.  And those branches, which
> > are supposed to be walled off from each other until explicitly
> merged,
> > now have a revision in common.  (*Every* file and dir in the branches
> > and tags dir trees now has the new, shared rev.)
> 
> It is strange behaviour on a conceptual level if you are used to
> thinking in terms of other version control systems (such as ClearCase
> in your case).
> 
> However, it is a natural consequence of the way Subversion is currently
> supposed to represent the concepts of versioning files and directories,
> and labels and branches. And it has done so for over a decade. Changing
> this behaviour is far from trivial.
> 
> I'm not entirely sure what kind of answer you are hoping to get.
> Are you happy with the answer that Subversion is simply not ClearCase?

I've been using svn since 1.3, so I'm aware of the design limitations.  And 
yes, I would recommend svn over clearcase in most situations.

Anyway, the whole exercise started when I needed a report script to find the 
common ancestor between two branches and ran into the 'parent dir change false 
revision' issue.  Then I started going through potential edge cases and 
realized just how fragile svn branches were (where fragile == dependent on 
human processes and conventions.)  Which in turn made me realize just how basic 
(i.e. bare metal) svn is in regards to "meta-features" such as branching, 
tagging, baselines, workflows, etc..  It makes me wonder if it would make sense 
to slap a higher-level interface on top of svn in order to implement the 
process aspects of version control (and otherwise hide/keep the lower level 
details/quirks away from users.)

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

> -Original Message-
> From: Les Mikesell [mailto:lesmikes...@gmail.com]
> Sent: Friday, May 10, 2013 11:00 AM
> To: Andrew Reedick
> Cc: Branko Čibej; users@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> 
> On Fri, May 10, 2013 at 8:40 AM, Andrew Reedick
>  wrote:
> >>
> > It's not a huge problem, but in the real world (i.e. a non-contrived
> > example) I have branches that have been locked and untouched for
> > months that now have a new HEAD revision.  And those branches, which
> > are supposed to be walled off from each other until explicitly
> merged,
> > now have a revision in common.  (*Every* file and dir in the branches
> > and tags dir trees now has the new, shared rev.)
> >
> > I can understand why it happens; svn log needs to know about the
> parent dir rename in order to know (and print) the correct paths for
> subsequent revisions.  It's a mostly harmless side effect of copy/mv,
> but it is odd looking and seems sloppy from a purist point of view
> because something outside of the branch is changing the branch's
> history and baseline albeit in a mostly limited fashion.
> 
> Isn't this just a difference in subversion's and your thinking about
> the significance of the path change?   Subversion is going to see the
> path change affecting everything below it because of the way it holds
> projects together.  Is there some reason you are changing a common
> parent path and thinking that it should not affect everything below?
> Is it 'above' what you think of as the actual project?
> 

Two words:  meta data.  A change in meta-data shouldn't change a branch's 
baseline.  Moving "/trunk" to "/project1/trunk" shouldn't change the contents 
of the trunk baseline.  Renaming a misspelled branch (/branches/rle1.0 to 
/branches/rel1.0) shouldn't change the contents of a branch/baseline.

So, from a technical point of view, where "svn has dirs, not branches," then 
yes, I would expect a parent dir change to do what it did.  From a 
process/philosophical point of view where branches represent baselines, then I 
would not expect a parent dir change to do what it did.

Anyway, it represents just one more potential quirk that you have to be aware 
of when using svn.  Fortunately, it's mostly harmless.  Long term, once svn's 
lower level features are mature (true renames, getting rid of --reintegrate, 
etc..) I would expect a push towards high-level process features such as 
branches as first class objects.

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

> -Original Message-
> From: Les Mikesell [mailto:lesmikes...@gmail.com]
> Sent: Wednesday, May 15, 2013 11:05 AM
> To: Zé
> Cc: Subversion
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> 
> On Tue, May 14, 2013 at 3:33 PM, Zé  wrote:
> >>
> > What has been said regarding
> > subversions lack of support for branching was, I think, quite clear.
> 
> Well, no.  The only thing you've made clear is that you don't like it
> or you don't understand how it is supposed to be used.  You have not
> explained why you lay your projects out so that you need to move the
> parent directories of your project around after creating branches.
> Nor have you made any real suggestions about how it might be improved
> in a way that doesn't break the ability to copy and subsequently merge
> any arbitrary subdirectory which is clearly a feature even though it
> doesn't mesh well with your concept of only having one way to branch.
> 

Isolating change is a fundamental tenet behind branching.  The fact that an 
"outside" change can affect a branch (and a tagged baseline) is wrong by 
definition.

Telling folks to never change their branching structure is a bit short-sighted 
given the lack of reliable precognitive ability in general and that 
occasionally folks like to clean up the branches and tags dir when they're 
cluttered with dozens of old branches and tags.  Telling folks not to run 'svn 
mv tags/1.0* archive/' simply isn't helpful.  Plus, telling people not use to 
svn's touted directory manipulation features because of side-effects is a bit 
self-defeating.


As for the various CVS comments in the thread, no one cares if Subversion was 
originally meant to be a better CVS.  Building a better CVS is akin to saying 
"let's build a better Model-T".  Personally, when it was announced that svn 
wouldn't include merge tracking, I wrote off SVN as useless for not including 
the basics.  Fortunately, merge-tracking and merging have come a long way since 
then and I, for one, am looking forward to 1.8 driving a stake in --reintegrate.

Furthermore, Subversion's vision statement is:
"Subversion exists to be universally recognized and adopted as an open-source, 
centralized version control system characterized by its reliability as a safe 
haven for valuable data; the simplicity of its model and usage; and its ability 
to support the needs of a wide variety of users and projects, from individuals 
to large-scale enterprise operations."

In the Future(tm), Subversion, IMHO, will need to treat branches (and tags) as 
first class objects because branches and tags are core concepts of modern 
version control systems.  To re-emphasize my point, isolated branches are an 
expected, fundamental, expected, and/or part of a minimal set of features that 
any VCS must support.  So please, no more references to "svn being a better 
CVS".  It's a very limiting and short-sighted thing to say.


Fortunately, the "parent dir changes affect branch history" problem is a minor 
hiccup.  There's no need to grab torches and pitchforks and rush to implement 
formal branches right now.  It's just something that needs to be kept in the 
back of people's minds once the merging, tree merging, and true renames are 
implemented and are mature.  I think that most folks can live with a spurious 
revision appearing in 'svn log' entry after a parent dir change.

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

> -Original Message-
> From: Bob Archer [mailto:bob.arc...@amsi.com]
> Sent: Tuesday, May 21, 2013 10:24 AM
> To: Zé; users@subversion.apache.org
> Subject: RE: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> 
> 
> .. snip
>
> You keep saying "svn doesn't support branches" yet I use branches every
> day. While there is no way to "list branches" it would be possible. I
> think the current implementation records the parent path in the branch,
> but not vice versa... I assume svn doesn't do this because it would be
> a change to the parent path and the svn design avoids modifying the
> repository on its own.

There are two definitions of branches; svn's definition of a branch (i.e. a 
dir) and the high-level definition of a branch (theory.)  The reason why svn 
doesn't "support branches" is because a svn branch is just a dir, a dir that is 
only a branch because it is given special meaning by Humans.  Internally, svn 
doesn't know or care if a dir is a branch or not.  

The distinction is important because one of the theoretical benefits of 
branching is isolation.  An outside change shouldn't affect the branch's 
contents.  Unfortunately, changing the parent path of a branch injects a 
spurious revision into 'svn log' and causes 'svn log --stop-on-copy' to stop 
early.  This is detailed in my original email that started this thread.

So when people say that svn doesn't have branches, they are saying that 
a) svn has directory objects, not branch objects, i.e. a svn branch is a branch 
by human convention only,
b) svn dirs lack the special protections expected of branches (e.g. being 
isolated from outside change), 
c) svn dirs lack the special abilities expected of branches, such as computing 
ancestry reliably.

Fortunately, in practice, "dirs-as-branches" works fine for the most part and 
any limitations tend to be minor.


> While there is no way to "list branches" it would be possible.

No-ish.  In the average case, "list branches" is easy.  Just iteratively run 
'log --stop-on-copy'.  However, there are edge cases that prevent "list 
branches" from being deterministic or otherwise make determining ancestry 
complicated. 

For example, is this a rename (to fix a misspelling) or a case where someone 
combined two steps: 1) creating a new branch and 2) deleting an obsolete branch?
svn copy branches/ofo-1.0  branches/foo-1.0
svn rm branches/ofo-1.0
svn ci
... creates revision 100 ...

If I want to find the start of the branch, I run 'svn log --stop-on-copy 
^/branches/foo-1.0' which will stop on revision 100. However, svn can't tell me 
if rev 100 is the start of the branch or whether it's just a spelling fix (in 
which case I need to run 'svn log --stop-on-copy' again.)  Hopefully, the Human 
who created rev 100 provided a meaningful commit message.

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: Saturday, May 18, 2013 4:17 PM
> To: Zé
> Cc: users@subversion.apache.org; David Chapman
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> 
> So what's the actual problem (or problems) with SVN's branching and
> tagging? Where does it hurt your workflow? What would make SVN not
> "hurt you" in that way?
> 
> Please be concrete, and give examples of what really bothers you as a
> user or an admin in your daily work. Saying that "branches are not
> first class", or "I don't like it that Subversion implements
> branches/tags by copying directories" are too abstract, and really not
> relevant. Why should I care how SVN implements its branches internally,
> as long as it works for the use cases I need?
> 
> The only concrete problem I've read so far (I don't remember if it was
> in this thread or another one) is that copying the parent of all
> branches (or tags) shows up as a revision when you "svn log" the
> branch. So okay, that's one thing. Any others?
> 

Correct, changing the parent dir of a branch injects a "spurious" log entry in 
your branches (or tags) sub dirs, which is morally wrong because branches (and 
tags) should be isolated from outside changes.  I documented this in the 
original post.  (Or, given "^/porject1/branches" and "^/porject1/tags", if you 
"svn copy ^/porject1 ^/project" to fix the naming problem then everything under 
branches and tags gets the spurious revision.  The spurious revision also 
triggers on --stop-on-copy which needlessly complicates ancestry tracking.

However, given how svn works, I'm not sure that it is technically a technical 
issue.  =)  Instead, is it a "branches as first class objects" requirement?

> 
> However, this discussion lacks focus, it sounds more like a
> philosophical debate, with large ideas being thrown against each other.
> If you want to get anything useful out of this discussion (be it
> planting the seeds for improvements to Subversion, or be it a deeper
> understanding for yourself of how to work effectively with svn), you'll
> have to get much more concrete.

IMO, it's not a philosophical debate per se, it's a requirements (or 
expectations) problem.  We have two points of view.  The first is the low-level 
technical point of view that is focused on being able to perform any operation 
at any point in the repository tree.  The second is the high-level point of 
view that needs a VCS to manage baselines, track ancestry, track merges between 
baselines, etc.  IMO, subversion right now is more of a VCS engine than a VCS 
"system."  Basically, it's the trees versus the forest view.

The friction is that the high-level point of view folks are probably your 
primary customers.  For example, when Subversion initially announced that merge 
tracking wasn't part of the initial architecture, I laughed and blew off svn as 
a complete waste of time due to intentionally lacking such a basic and 
essential VCS feature.

Now that svn has implemented merge tracking, tree merging, and the long overdue 
death of --reintegrate in 1.8, I think it's getting close to the point that svn 
needs to step back and consider the forest view, e.g. true branches, proper 
ancestry tracking (instead of --stop-on-copy), etc., in order to maintain 
relevance.  Meaning, svn's paradigm/workflow will need to focus on baselines 
(aka branches) instead of files and dirs because, in my experience, VCS users 
are most concerned about slinging baselines around and tracking changes to 
baselines (i.e. has all work for the release (baseline) been completed, merged, 
and tested?)  

Disclaimer:  All IMHO.

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

> -Original Message-
> From: Thorsten Schöning [mailto:tschoen...@am-soft.de]
> Sent: Tuesday, May 21, 2013 12:30 PM
> To: users@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> 
> Guten Tag Bob Archer,
> am Dienstag, 21. Mai 2013 um 17:54 schrieben Sie:
> 
> > Frankly, if you are
> > writing to tags it is more like a branch. ;)
> 
> Of course, that's why it's all about definitions or conventions and my
> writable tags are customer installations of our software which get
> updated to new versions and are used to track configuration changes.
> Nothing I would like to implement using only top level branches and as
> no active development takes place on those directories, I see them
> rather as tags, than branches.
> 

I think of tag-branches as effort saving devices that spare me from having to 
svn copy tags/PRODUCTION branches/production
vi branches/production/config.conf 
...
svn rm tags/PRODUCTION 
svn copy branches/production tags/PRODUCTION
when a hostname changes in prod and I need to backfill a config file.

Should we call them tag-branches or branch-tags?  And should they be first 
class objects?  ;-)

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

> -Original Message-
> From: Bob Archer [mailto:bob.arc...@amsi.com]
> Sent: Tuesday, May 21, 2013 1:24 PM
> To: Andrew Reedick; Johan Corveleyn
> Cc: users@subversion.apache.org; David Chapman
> Subject: RE: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> 

> 
> What do you mean by "spurious" log entries? When I look at the log (at
> least in the tsvn log viewer) I only see revisions that have changes on
> that path. I don't see every revision number unless I go to the project
> root path or repository root path.
> 

1. Create /tags/tag1, /tags/tag2, etc.. 
2. Pretend that your tag1, tag2, etc. dirs are immutable, static, locked down, 
and haven't be touched in months.
3. svn log -v --stop-on-copy ^/tags/tag1
   svn log -v --stop-on-copy ^/tags/tag2
   etc.
4. # Move your tags dir under a project1 dir
   svn mv -m "" --parents ^/tags ^/project1/tags
5. svn log -v --stop-on-copy ^/project1/tags/tag1
   svn log -v --stop-on-copy ^/project1/tags/tag2
   etc.

Ooops.  All of your immutable, static, locked down, haven't been touched in 
months tags now have a new revision, and they all share that revision in 
common.  The parent dir change from "/tags" to "/project1/tags" is visible 
under the tag1, tag2, etc. baselines because svn doesn't know that 
"^/project1/tags" isn't/shouldn't be part of your "tag1", "tag2", etc. 
baselines.

However, the Last Changed Revision of the tag1, tag2, etc. dirs doesn't change, 
so the effect is mostly visual.

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

> -Original Message-
> From: Les Mikesell [mailto:lesmikes...@gmail.com]
> Sent: Tuesday, May 21, 2013 11:41 AM
> To: Bob Archer
> Cc: Zé; users@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> 
> 
> Of course you can 'list branches' as long as you follow and remember
> _your_ convention for where they are. You can also delete them to the
> extent that they don't show up in this list (even though they can still
> be accessed with peg revision syntax and the actions show in the
> log history of the parent directory).   This is nicer in many ways
> than just having one special-case 'branch' namespace, especially when
> you have many projects in the same repository and/or you like to
> separate your release, QA, and experimental branches so different
> groups don't have to deal with the clutter from the others.
> Subversion doesn't force you to follow good conventions (and I think
> this thread started because someone didn't and the rename of a
> directory above where they put a branch was recorded as a change in
> both the branch and its parent), but you can if you want.
> 

Right, right, it's the user's fault for failing to predict future "namespace" 
needs.  That the repository was created when the project was small and that the 
user in question inherited the repo aren't valid excuses either.

Next time I'll implement top level directory changes via 'svnadmin dump/load' 
to avoid spurious log entries under branches/tags. 


Translation:  Les, that wasn't a very realistic or helpful piece of advice. 

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

> -Original Message-
> From: Les Mikesell [mailto:lesmikes...@gmail.com]
> Sent: Tuesday, May 21, 2013 2:33 PM
> To: Andrew Reedick
> Cc: users@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> 
> 
> I'd call realizing that most software isn't perfect being realistic,
> and learning to live with the imperfections to be more helpful than
> waiting for everything to work the way you expect.   Maybe in this
> specific case some kind of event metadata could be added to note your
> intent to create a branch or tag and that could be used instead of --
> stop-on-copy to avoid confusing what you think of as tags and other
> copies.
> 

Metadata could work.  A "svn mkbranch" command that would run "svn copy" plus 
"svn propset" indicating that this is a branch root.  "svn copy" would be 
restricted from operating in the branches or tags dir (as indicated by another 
property.)  "svn log --stop-on-branch" would then check for the metadata.

Although if I was going to modify the client that much, I might as well 
internally store branches as "^/UUID" and map the UUIDs to a human label, e.g. 
"project1/1.0" or "project1/trunk".  That would eliminate the troublesome 
"admin" level dirs from the repo and essentially implement "true branches"?  
And this would only be a presentation change thus negating the need to change 
how svn works internally.

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: Tuesday, May 21, 2013 2:32 PM
> To: users@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> 
> On 21.05.2013 20:26, Branko Čibej wrote:
> >
> > You cannot identify a directory (or branch or tag) just by its
> > basename, only the whole path is a unique identifier (within the
> repository).

Yes, I understand why it happens and why it needs to happen.
 
> Just to be clear -- I agree that the the result of 'svn log --stop-on-
> copy' changes is confusing. And, as I said (much) earlier in this
> thread, that's an unfortunate side effect of how renames are currently
> implemented. Personally I've always viewed the --stop-on-copy as a
> hack, and we really should invent a better way of identifying branch
> points.
> 

I don't think true renames will necessarily fix the problem.  Conceptually, the 
problem is that the parent dir components of a branch/tag are superfluous, e.g. 
given "svn://server/repo/path/to/project1/branches/1.0", the 
"svn://server/repo/path/to" and "branches" path components are 
useless/meaningless to the average user.  However, these superfluous dir 
components are visible to the client, which means they're accessible by, and 
thus modifiable by the client.  Which makes them superfluous *and* dangerous.  
The client should only see and work with "--project project1 --branch 1.0", 
e.g. "svn co --project project1 --branch 1.0" to checkout a branch.  

It's about presentation.  Keep the superfluous dir components internal and 
hidden from the average user.  We've already seen a move towards information 
hiding with the'^' syntax that hides the server component.  This would be the 
logical progression.


Anyway, I'm nearly done with implementing my "find common ancestor" script that 
seems resistant to edge conditions, so I'll stop rambling.

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: Tuesday, May 21, 2013 3:36 PM
> To: users@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> 
> On 21.05.2013 21:27, Andrew Reedick wrote:
> > Anyway, I'm nearly done with implementing my "find common ancestor"
> > script that seems resistant to edge conditions, so I'll stop
> rambling.
> 
> Ah ... if that's what started the whole thread ... have you considered
> that the Subversion libraries already have that functionality, and that
> it's accessible through a number of script language wrappers?
> 

Will the libraries get tripped up by "spurious" revisions created by parent dir 
path changes?

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

> -Original Message-
> From: Les Mikesell [mailto:lesmikes...@gmail.com]
> Sent: Tuesday, May 21, 2013 3:53 PM
> To: Andrew Reedick
> Cc: Branko Čibej; users@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> 
> 
> > The client should only see and work with "--project project1 --branch
> 1.0", e.g. "svn co --project project1 --branch 1.0" to checkout a
> branch.
> 
> That's sort of like saying filesystems shouldn't have subdirectories so
> users don't get confused...  Some people might even believe that.

And there's a reason why 'pwd' returns '/home/userid' instead of 
'/dev/sda1/home/userid' or 'server-vol0.foo.net:/vol0/userid'.  Or why 'cd ~' 
takes you to your home dir.  

> 
> > It's about presentation.  Keep the superfluous dir components
> internal and hidden from the average user.  We've already seen a move
> towards information hiding with the'^' syntax that hides the server
> component.  This would be the logical progression.
> 
> It's about organization.  And letting you arrange your own conventions
> to match your processes.


We'll have to agree to disagree.  We're back at the low level "managing dirs" 
versus high-level "managing baselines" arguments/thinking/paradigms.

RE: Merging change sets for a production release,

[Andrew Reedick]

> -Original Message-
> From: Gavin Baumanis [mailto:gbauma...@cogstate.com]
> Sent: Monday, June 03, 2013 12:31 AM
> To: users@subversion.apache.org
> Subject: Merging change sets for a production release,
> Importance: High
> 
> At the moment we do all of our work on /trunk and also have
> /branches/releases/1.0 When we have enough issues, we mark the ready /
> required issues with a new release milestone and I go about the task of
> merging the required changes from trunk to the release branch.

Is there a reason why you all are not doing Release Planning ahead of time?

 
> Here is what I am currently doing, that is giving me some issues, and I
> am hoping someone might be able to see what I am doing wrong / have
> some advice / comments to better the process I am using.
> 
> Let's assume that I have multiple completed issues ready to merge from
> trunk that will become the "Changes" from the last version.
> Let's also assume that I have multiple subversion commits per issue -
> sometimes ~20 commits can be assigned against an issue.
> Let's also assume that the very same files that have the required
> changes to go to the new release - have other, not-ready for release
> changes made to them too.
> 
> The scenario seems pretty ordinary to me - but I could, of course, be
> completely wrong.
> 
> Anyway,
> So I open the first issue, notice there are 3 commits assigned to this
> issue.
> The first commit has 3 files,
> I do a cherry pick merge from trunk for each of the individual files
> listed in the issue.
> 
> (Ignoring the paths...)
> svn merge -c 1234 /trunk/myPath/myFile1.c
> /branches/release/myPath/myFile1.c
> svn merge -c 1234 /trunk/myPath/myFile2.c
> /branches/release/myPath/myFile2.c
> svn merge -c 1234 /trunk/myPath/myFile3.c
> /branches/release/myPath/myFile3.c
> 
> I manually resolve any conflicts that I may have.
> 
> I then open the 2nd issue and repeat the process above as required for
> the change sets listed in the 2nd issue.

Is each svn commit tied to an issue?  Meaning, are all the changes in a single 
revision tied to an issue?

You shouldn't need to merge individual files.  Just do a 'svn merge -c 
100,110,...,N svn_url' and let svn walk through the cherry-picked merges.

> 
> A "problem" I am having is that I tend to get a lot of Merge conflicts
> doing it this way.
> 
> But my biggest problem and the purpose for this email is; I might have
> a quite a few helpdesk issues to create a new release from.
> The same file might be edited in numerous issues.
> I often find myself doing a merge of a revision number less than one I
> have already performed.
> (depending on the order that I do the issue merging, of course)
> 
> And "oddly" to me - I find at times when this is the case that my
> initial merge to the release branch is negated / overwritten.
> 
> I am certain that it is a usage issue - but short of somehow ensuring
> that I do all the required merges in order - which is simply just too
> difficult to achieve - I find myself constantly battling with ensuring
> that the release branch is updated with all that this is necessary.
> 
> If anyone has any ideas I would be most grateful.

Change your process.  

Brick Wall Analogy:
Imagine that trunk is a brick wall built with 100 bricks (issues.)  You're only 
merging 80 bricks (completed issues) to the release branch.  The 20 missing 
bricks can result in gaps in your wall that are structurally unsound, or could 
even result in bricks floating in mid-air due to dependency issues (supporting 
bricks/issues were not merged over.)  It's a crazy, slow, and stressful way to 
build a wall.

IMO, you have several problems:
1) A lack of release planning.  You all don't decide on what's going into a 
release until after the work is done.  Which means you don't take dependencies 
into account.  You don't take development time into account which can result in 
continual merge conflicts since you are always having to skip over commits 
related to the long running work-in-progress issue.  You wind up mixing an 
inordinate amount of complete and incomplete code together which dramatically 
increases the number of merge conflicts.  And so on.  Doing "release planning" 
at the end of the cycle ends up requiring more work (i.e. conflicts, merge 
headaches, a very slow release process) and can require pulling in dev 
resources to resolve merge issues (which interrupts their current work, and 
requires them to look at code that's no longer fresh in their mind, which is a 
very inefficient way to work.)

In other words, "prior planning prevents poor performance."  Decide what's 
going into a particular release instead of using /trunk as a dumping ground for 
random changes, especially when those changes have dependencies (aka merge 
conflicts.)  You'll probably want to triage your issues and assign them to a 
branch (e.g. "fixVersion" in JIRA.)  Then use a pre-commit hook to reject 
check-ins unless the issue's "fixVersion" matches the bra

RE: Merging change sets for a production release,

[Andrew Reedick]

> -Original Message-
> From: Gavin Baumanis [mailto:gbauma...@cogstate.com]
> Sent: Monday, June 03, 2013 2:27 PM
> To: Andrew Reedick; users@subversion.apache.org
> Subject: RE: Merging change sets for a production release,
> 
> Hi Andrew,
> Thanks for your response.
> 
> I do everything but for the chaining of the revisions to merge in the
> same command.
> I tried it once (granted a long time ago) and it caused such an issue
> for me  that after about 6 hours of swearing, I finally gave up and
> reverted the changes and did the merges one by one.
> At the time one by one allowed for individual merge conflicts - which
> made life a little easier.
> 
> As for the other ideas, we do already only merge changes from trunk
> that are complete and have been given the appropriate release
> milestone.
> Our release process is already issue-based.
> 
> Perhaps simply chaining the merge revisions is the answer?
> 

Yes, I would try the 'svn merge -c ...' "changed" merge again.

Assuming you're using SVN 1.7, "chained" merges should be much easier.  It is 
still an iterative process, in that if a merge conflict is encountered, svn 
will prompt you for what to do, then you fix the code, resolve the conflict, 
and re-run the merge command to pick up where it left off.  You will probably 
want to use 'svn merge --accept postpone ...' to avoid the prompting.  It's 
normally a good idea to save off your merge command so you can add it to the 
commit comment (or in case anything happens to your command line's history 
buffer.)

RE: Tree conflict on Fresh checkout

[Andrew Reedick]

> From: James Hanley [mailto:jhan...@dgtlrift.com] 
> Sent: Tuesday, June 04, 2013 1:44 PM
> To: users@subversion.apache.org
> Subject: Tree conflict on Fresh checkout
>
> We are seeing a strange anomaly after our last check-in - on fresh checkout 
> there is a tree conflict into a new path - I've included the output below.
>
> $ svn status
> D C Project/settings/MkImage
> >   local unversioned, incoming add upon update
> D   Project/settings/MkImage/Makefile
> D   Project/settings/MkImage/defs.h
> D   Project/settings/MkImage/main.c
> Summary of conflicts:
> Tree conflicts: 1

Any chance it's a case issue, i.e. MkImage versus mkimage in the same dir?  Do 
an 'svn ls Project/settings'.

And are you using a Windows svn client in a cygwin bash shell, or the cygwin 
built svn client?

RE: Tree conflict on Fresh checkout

[Andrew Reedick]

> From: James Hanley [mailto:jhan...@dgtlrift.com] 
> Sent: Tuesday, June 04, 2013 3:12 PM
> To: Andrew Reedick
> Cc: users@subversion.apache.org
> Subject: Re: Tree conflict on Fresh checkout
>
> I can reproduce on the versions specified above of the CygWin svn client 
> within CygWin, but I haven't tried the native windows svn client. Strange 
> thing is that this is only an issue with MkImage, and MkSharedData...
>
> user_dude@computer_node ~/projects/my_project/my_project_03b_pristine
> $ svn ls -v Project/settings
>2528 cm_user  May 30 19:28 ./
>...
>2528 cm_user  May 30 19:28 MkBinFile/
>2528 cm_user  May 30 19:28 MkImage/
>2528 cm_user64131 May 30 19:28 MkImage.exe
>2528 cm_user  May 30 19:28 MkSharedData/
>2528 cm_user59528 May 30 19:28 MkSharedData.exe
>...
>2209 cm_user   85 May 07 12:52 run.cmd
>
> user_dude@computer_node ~/projects/my_project/my_project_03b_pristine
> $


'svn ls' sorts output and the sort is case sensitive.  Since you truncated your 
output, we can't tell if you have a case sensitive filename problem.  Run 'svn 
ls -v Project/settings | grep -i mkimage' to see if you have duplicate 
"mkimage" entries.


Under 1.7.9, I get a tree conflict when I have "alpha" and "Alpha" in the same 
dir under Cygwin.
$ svn ls -v svn://localhost/test/case
111 test  Jun 04 15:18 ./
111 test  Jun 04 15:18 Alpha/
110 test  Jun 04 15:18 alpha/

$ svn co svn://localhost/test/case
Acase/Alpha
   C case/alpha
Checked out revision 111.

$ svn status case
D C case/alpha
  >   local unversioned, incoming add upon update
Summary of conflicts:
  Tree conflicts: 1


Finally, if you're using Outlook, when composing an email for the list, click 
Options -> Plain Text.

RE: Tree conflict on Fresh checkout

[Andrew Reedick]

> From: James Hanley [mailto:jhan...@dgtlrift.com] 
> Sent: Tuesday, June 04, 2013 1:44 PM
> To: users@subversion.apache.org
> Subject: Tree conflict on Fresh checkout
>
>  A    my_project_03b_pristine/Project/settings/MkSharedData.exe
>   C my_project_03b_pristine/Project/settings/MkImage
>   A my_project_03b_pristine/Project/settings/MkImage/main.c
>   A my_project_03b_pristine/Project/settings/MkImage/defs.h
>   A my_project_03b_pristine/Project/settings/MkImage/Makefile
> A    my_project_03b_pristine/Project/settings/hex_to_hex.exe
>
> user_dude@computer_node~/projects/my_project/my_project_03b_pristine
> $ svn status
> D C Project/settings/MkImage
>  >   local unversioned, incoming add upon update
> D   Project/settings/MkImage/Makefile
> D   Project/settings/MkImage/defs.h
> D   Project/settings/MkImage/main.c
> Summary of conflicts:
>  Tree conflicts: 1

Duh.  The 'C' is in the 2nd column, which means there's a conflict with the 
properties.  However, I'm not sure why you would have a properties conflict on 
a checkout in svn 1.7.

RE: History in subversion

[Andrew Reedick]

> From: Olivier Antoine [mailto:oliviera201...@gmail.com] 
> Sent: Tuesday, June 11, 2013 4:45 PM
> To: users@subversion.apache.org
> Subject: Re: History in subversion
>
> Thanks for your help, I will try again this.
> But this is very poor compared to ClearCase. Nobody tried to script that ?

I used to use ClearCase in a past life (3.0 - 6.0).  I haven't missed the 
ability to diff dirs.  You might be stuck on doing things the CC way instead of 
learning the Subversion paradigms.  It's going to be frustrating for a little 
while (it was for me.)

What are you trying to do that requires diff'ing the contents of directories?


> It is also possible to read the SVN repository without checkout, there is a 
> way to address an element, something like this :
> @revnumber
> But it is not possible to use a syntax like this :
> @revnumber/

You want to read up on peg revisions:  
http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html  

You don't need to specify the rev for each path in the component, e.g. 
"/view/foo/path@1/foo@2/bar@3/j.java@5".  In SVN, the rev number is global, so 
you just "/path/foo/bar/j.java@5".


> I tried, it doesn't work.
> Actually, I just try to analyze all elements, files and directories, 
> contained in a SVN repository. I'd like to be able to parse all the elements 
> - if possible without any checkout (that would be great).

Use "svn export" (or for individual files, "svn cat")

> Other challenge is : I need to restore a file element that has been removed 
> in a very old revision, and of course I don't know which one.
> Any search command or script with Subversion ?

You'll need to use a peg revision, e.g. "svn copy svn:///path/foo.java@1234 
."  To find the revision that the file was in can be tricky if you have deleted 
a parent dir.  In the average case, you can run "svn log -v -q ^/path/to/branch 
> log.txt".  Then search the text file for your missing file to get the 
revision.  You can also use "svn log -v -q | egrep '^r|\/foo.java'".  Worse 
case (you deleted a parent dir), you'll need to run the 'svn log' against the 
root of the repository (svn log -v -q ^/).


To re-emphasize, I'm very serious about the need to stop trying to apply CC 
paradigms to SVN.  It's frustrating, and, in my experience, the CC way of doing 
things didn't provide significant advantages in (or over) SVN.

RE: History in subversion

[Andrew Reedick]

> From: Olivier Antoine [mailto:oliviera201...@gmail.com] 
> Sent: Wednesday, June 12, 2013 3:42 PM
> To: users@subversion.apache.org
> Subject: Re: History in subversion
>
> Thanks All for your help and advices,

> But :
>
> With CC, I can easily search for any file element in a repository, and 
> directly get its path,
> With SVN, I have to check all revisions, then I can know where this element 
> is located in the repository (maybe several locations), I can find in which 
> revision it was removed.
> This is double manual search.

You cannot directly diff two revisions of a directory, where diff is defined as 
diff'ing the list of file/dir objects in the directory.  Instead, SVN will diff 
the files under the directory tree.  From a CC point of view, svn file objects 
are first class objects with version a version tree, history, etc., whereas SVN 
directory objects are not.  (SVN dirs are second class-ish.)

This should help you to find files and what rev they're in.  '^/' is the path 
or svn url to check.  Foo.java is the file or regex you're looking for.
svn log -v -q ^/ | perl -ne '$r=$_ if /^r\d+/; print $r, $_ if 
/foo.java/;'


> When users ask for help, I have to go in their repository that I don't know 
> at all, users often give less than half the information I need to locate the 
> file where they need help.
> With CC, I can quickly analyze a repository, and get easily the missing 
> information.
> With SVN, I feel like blind, because I cannot do the same analysis on the 
> repository. I cannot do a global search, I have to check the revisions 
> individually.

If you're just trying to find a file in the current version of the repo, then 
"svn ls -R svn://..."  You can use '-r' and peg revisions to search older 
revisions of the repo tree.


> About peg revision :
> Peg revision means that I can access any file and directory "version" without 
> checkout, this is already a nice help.
> But : is there also an individual identifier for directory and file (uuid, 
> oid, ..) ? 

There's no such thing as a uuid or oid in SVN (or at least one that is user 
visible.)  Instead, you can use "svn_url + revision number" or "svn_url + 'Last 
Changed Rev'" (which can be found via 'svn info') in order to uniquely identify 
a particular revision of something.  'Last Changed Rev' is preferable.

However, since SVN doesn't have true renames, 'svn copy' will normally create a 
new object with a new revision (aka last changed rev) number.  A new revision 
number won't be created if you copy the parent dir the file is in.  In CC 
parlance, instead of /repo/branches/1.0/foo.java and /repo/trunk/foo.java just 
being hard links to revision object #1452134521, in svn you wind up with either 
a new revision number:
1. svn copy /repo/trunk/foo.java /repo/branches/1.0/foo.java
2. svn info /repo/trunk/foo.java /repo/branches/1.0/foo.java
   ...
   Last Changed Rev: 100
   ...
   Last Changed Rev: 123
Or if you copy the parent dir, foo.java's rev number remains unchanged:
1. svn copy /repo/trunk /repo/branches/1.0
2. svn info /repo/trunk/foo.java /repo/branches/1.0/foo.java
   ...
   Last Changed Rev: 100
   ...
   Last Changed Rev: 100

So technically yes, SVN has the Evil Twin problem, however, it doesn't really 
cause problems with file merges per se, so Evil Twins aren't really a problem.  
Directory tree merges on the other hand, can be murder, but tree conflicts have 
been greatly improved in 1.7.


> Could you help more on diff dirs, please :
> - What is the best way with SVN to compare a same directory on two different 
> branches ?

'svn diff', or checkout/export both branches (directories) and run your 
favorite diff tool on them.  If you want to diff the contents of the dirs (i.e. 
the hard links,) then you can try 'svn ls -v' and diff the output (look at the 
rev numbers.)  Generally speaking, in SVN, you don't diff directories, you diff 
the files in the baselines (aka branches.)  

However, since SVN revisions are changesets (a collection of related changes,) 
you can also use 'svn mergeinfo' to "diff" two baselines/branches/directories 
(i.e. find what changes have not been applied from branchA to branchB.)  Or you 
can just run the merge command to see what would get merged and then 'svn 
revert -R' to get back to a clean workspace (instead of checking in.) You can 
even do a a 'svn merge --ignore-ancestry' to merge unrelated trees 
(http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.nomergedata)

Long story short, if you are managing changesets between branches, then svn is 
quite adequate.  If you're diffing code trees, then something has gone wrong 
with your merges and/or change management process.  =)



> I am very confused by many things with SVN, one of them is :
> - I can merge from any directory to any directory anywhere, and I just get a 
> terrible Tree conflict.
> With CC, the merge is inside the version t

RE: History in subversion

[Andrew Reedick]

> From: Olivier Antoine [mailto:oliviera201...@gmail.com] 
> Sent: Thursday, June 13, 2013 3:57 PM
> To: users@subversion.apache.org
> Subject: Re: History in subversion
>
>
> Thanks All again for your help,
> 
> 
> > If you're just trying to find a file in the current version of the repo, 
> > then "svn ls -R svn://..."
> > You can use '-r' and peg revisions to search older revisions of the repo 
> > tree.
> 
> Yes, I started a short perl script for this, but this is strange that nobody 
> asked for a svn+find command (IMO).

Because in SVN, you're normally working in a workspace and not directly in the 
repository.  'svn log' is your 'ct find' in most cases.  Plus, in SVN you're 
working in a workspace most of the time and the normal command line tools (e.g. 
find, dir /s) work just fine, so there's not much need to re-create the wheel 
with SVN equivalent commands.  You need 'ct find' because all the history is 
tracked in each individual element, whereas in SVN, history is contained in 
each (global) revision.  

In other words, you're probably trying to apply CC paradigms to SVN.


> Tree conflicts seem to be very mysterious. Why is there a such issue in SVN 
> and not CC - what to think about this, please ?

Directory merging wasn't in the initial design architecture of SVN...  It's 
been added in bits since 1.4(?) and hasn't really gotten good until 1.6/1.7.


> And of course : Is it possible to do refactoring on any branch, and to merge 
> to any branch without trouble ?

Mostly.  Again you have to deal with the limitations of 'merge --reintegrate' 
in 1.7.x (which goes away in 1.8.)

If you are merging unrelated code (i.e. no common ancestor) then you're asking 
if SVN can merge Evil Twins.  I think the answer is mostly yes, but I could be 
wrong because it's rare that I encounter that situation.

Ideally, your branches have a common ancestry in order to make merge conflict 
resolution easier.  You can ignore ancestry to merge unrelated trees, but if 
you find yourself merging often between unrelated (i.e. no common ancestor) 
branches, then I would hazard to say that there's something wrong with your 
branching process and/or baseline management (i.e. barring an exceptional use 
case, you might be using SVN incorrectly or working against SVN's branching 
paradigm?)



> Like I said above, I wish to continue :
> - to create tags on branch (and to keep the link of the tag with the branch)
> - and to create a branch from a tag (and to keep the information that the 
> branch starts from this tag).
> 
> These are raisonnable SCM principles, don't you think ?

SVN does that.  But instead of applying labels to each element, svn simply 
makes a complete copy (i.e. cp -pr branch1.0 tags/REL_1.0).  In CC terms, it's 
conceptually similar to adding '-mkbranch REL1.0' to a config_spec and doing a 
checkout/checkin on each element to create the REL1.0 branch.  And then locking 
the REL1.0 branch so folks don't check into it.  (But SVN's branching/tagging 
is very efficient and fast.)

You can get the link back to the branch point via 'svn log --stop-on-copy -v -r 
1:HEAD -l 1'.  (But there is an edge case which breaks that, requiring 
iterative use of 'svn log --stop-on-copy'.  *grumble*) 


> I think that dynamic view is still a nice concept. Dynamic views is something 
> that users like much, and they desespair when they have to migrate to 
> snapshot views.
> You create your view, you have an (almost) real-time connection to the 
> repository, your view is available immediatly on all the machines.
> The working copy needs to be loaded, recreated and reloaded on each machine.

Back in my day, CC snapshot views were terrible/horrible/nearly_unusable.  SVN 
workspaces are simply great.  I doubt your users will complain once they start 
using them.  IME, the only downside to SVN workspaces/snapshots is that 
developers will whine about having to checkout a full directory tree no matter 
how small the tree.  'svn switch' helps reduce the need to checkout full 
workspaces, but it still doesn't reduce the whining though.  :(


> But I never saw another tool with these principles : real-time access to 
> repository, build based on version (not on time), winkin, configuration 
> audit, SCM process level (stream, baseline, component), multisite.

Yes, but in practice, you don't really need real time access to a repository.  
In SVN, you do your work, then when you're ready, you run 'svn update' to pull 
in other people's changes.  Meaning, you decide when to take changes instead of 
having random changes spontaneously appear in your view.

It helps to remember that SVN was designed to support open source projects with 
developers spread across the world.  It's why hooks are server side only 
(instead of client side hooks,) why workspaces are "snapshots" instead of 
dynamic views, why svn URLs are URLs, etc.

RE: Ancestrally Related Error Message

[Andrew Reedick]

> From: C M [mailto:cmanalys...@gmail.com] 
> Sent: Monday, June 17, 2013 12:39 PM
> To: C. Michael Pilato
> Cc: Subversion
> Subject: Re: Ancestrally Related Error Message
>
> I think my earlier mistake might have been that I was using the --reintegrate 
> option. 
> Without it, I make some progress, but still not quite what I am expecting.
> Again, given that trunk is empty, why the "C" (tree conflicts)? I would 
> expect all of then to be "A" (additions), no?
> The DEV_WC currently only shows the two dirs which SVN correctly recognized 
> as additions.
>
> c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry 
> https://path_to_branch/SCR_BR/
>
> --- Merging r1191 through r1245 into '.':
>   C ini
>   C txt
>   C graphics
>   C MMI
>   C backups
>   C sysctrl

>   C cpu
> A    mtl
> Summary of conflicts:
>   Tree conflicts: 8

What kind of tree conflicts are they?  'svn status' should provide more detail. 
 Also, what version of svn are you using?  1.6? 1.7?

Why is trunk empty?  Because you deleted trunk after the branch was created? 
(i.e. create branch, delete trunk/*, merge from branch.)

I get the vague feeling that you have 'incoming add after delete'(?) type 
messages on the directory conflicts.