RE: confusion over external svn diff and merge on windows

[Adam Downer]

> 
> If you just run 'kdiff3' from the shell prompt, do you get another
shell
> prompt before or after you close diff3?
>
> It should be the latter.

Good thought, it is the latter.




PLEASE NOTE THAT WE HAVE MOVED.
Our new address is 4th Floor, Dashwood House, 69 Old Broad Street, London, EC2M 
1QS. Our new telephone number is +44 (0) 20 3535 8300.

This e-mail and its attachments are confidential. If you are not the intended 
recipient of this e-mail message, please telephone or e-mail us immediately, 
delete this message from your system and do not read, copy, distribute, 
disclose or otherwise use this e-mail message and any attachments. 

Although RI3K believes this e-mail and any attachments to be free of any virus 
or other defect which may affect your computer, it is the responsibility of the 
recipient to ensure that it is virus free and RI3K does not accept any 
responsibility for any loss or damage in any way from its use.

RI3K Limited is a company registered in England no: 3909745. Registered office 
4th Floor, Dashwood House, 69 Old Broad Street, London, EC2M 1QS. VAT 
registration no: 769 0192 07

Re: Size of Subversion repository

[Daniel Shahaf]

Loren M. Lang wrote on Wed, May 04, 2011 at 17:39:57 -0700:
> The format file says 3 so I might have made it with 1.3.x.

This conclusion is wrong.  The format number is NOT the minor release
number (because we may bump it multiple times between successive minor
lines).

Re: Size of Subversion repository

[Hyrum K. Wright]

2011/5/5 Thorsten Schöning :
> Guten Tag Loren M. Lang,
> am Donnerstag, 5. Mai 2011 um 02:39 schrieben Sie:
>
>> We have been using Subversion 1.4.x for quite some time and just earlier
>> this year, we upgraded to 1.5.x.  Our repository is still the same as we
>> did no dump/load between upgrades.  I was curious to see what kind of
>> space savings we might have if we did.
>
> I recently started syncing our old repositorys, all fsfs and created
> with Subversion versions 1.4.x and earlier, to a new server with most
> repositories created with Subversion 1.6.x and only standard features
> enabled. It's about 7,2 GB vs. 6,2 GB with one of our largest
> repositories on the sync target still in an older fsfs format. Seems
> it worth to do a complete dump/load cycle and the newer repository
> formats also have a feature called rep-sharing, where data is stored
> only once for the complete repository.

You also have the option of packing a repository created with or after
1.6.x.  For packing, earlier repositories can be upgraded in place,
rather than being dump/loaded.

-Hyrum

Re: Subversion 1.6.17?

[Neil Bird]

Around about 27/04/11 05:09, Hyrum K. Wright typed ...

The bugfix has been merged to the 1.6.x branch, so that's the one to
be testing now:
http://svn.apache.org/repos/asf/subversion/branches/1.6.x/


  FWIW, 1.6.x now works for me on this issue (I had previously proven the 
1.6.x-issue371 branch).  Of course, all that really means is that the svn 
merge worked OK :)



  Roll on 1.6.17;  thanks guys!

--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

Re: Size of Subversion repository

[Loren M. Lang]

On Thu, 2011-05-05 at 15:43 +0300, Daniel Shahaf wrote:
> Loren M. Lang wrote on Wed, May 04, 2011 at 17:39:57 -0700:
> > The format file says 3 so I might have made it with 1.3.x.
> 
> This conclusion is wrong.  The format number is NOT the minor release
> number (because we may bump it multiple times between successive minor
> lines).

Is there a list of these format numbers and their meanings/features?
I'm curious what I missed by not upgrading to 4 when I had the chance.

> 

Re: Size of Subversion repository

[Daniel Shahaf]

Loren M. Lang wrote on Thu, May 05, 2011 at 14:32:37 -0700:
> On Thu, 2011-05-05 at 15:43 +0300, Daniel Shahaf wrote:
> > Loren M. Lang wrote on Wed, May 04, 2011 at 17:39:57 -0700:
> > > The format file says 3 so I might have made it with 1.3.x.
> > 
> > This conclusion is wrong.  The format number is NOT the minor release
> > number (because we may bump it multiple times between successive minor
> > lines).
> 
> Is there a list of these format numbers and their meanings/features?
> I'm curious what I missed by not upgrading to 4 when I had the chance.
> 

https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/fs.h
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/fs.h
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure

> > 
> 
> 

Re: AW: Size of Subversion repository

[Loren M. Lang]

On Thu, 2011-05-05 at 08:00 +0200, Markus Schaber wrote:
> Hi, Loren,
> 
> Did you try "svnadmin pack" on the repositories?

svnadmin pack is a new feature of 1.6.x.  As I stated in my email, I am
using 1.5.x.  Would pack reduce space on a freshly loaded repository?
I'd assume it would pack it tightly on a load operation.

> 
> Best regards
> 
> Markus Schaber
> 
> ___
> We software Automation.
> 
> 3S-Smart Software Solutions GmbH
> Markus Schaber | Developer
> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax 
> +49-831-54031-50
> 
> Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
> CoDeSys internet forum: http://forum.3s-software.com
> Download CoDeSys sample projects: 
> http://www.3s-software.com/index.shtml?sample_projects
> 
> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
> register: Kempten HRB 6186 | Tax ID No.: DE 167014915 
> 
> > -Ursprüngliche Nachricht-
> > Von: Loren M. Lang [mailto:lor...@north-winds.org]
> > Gesendet: Donnerstag, 5. Mai 2011 02:40
> > An: users@subversion.apache.org
> > Betreff: Size of Subversion repository
> > 
> > We have been using Subversion 1.4.x for quite some time and just earlier
> > this year, we upgraded to 1.5.x.  Our repository is still the same as we
> > did no dump/load between upgrades.  I was curious to see what kind of
> > space savings we might have if we did.  Our original repository is fsfs
> > and was created under 1.4.x as far as I remember.  The format file says
> > 3 so I might have made it with 1.3.x.  The format for the new repo is 5.
> > Here are the numbers for two tests I did, one with fsfs and one with bdb.
> > 
> > 737Msvn-original
> > 690Msvn-fsfs
> > 903Msvn-bdb
> > 2.3Gtotal
> > 
> > Are these numbers typical?  And why is BDB so significantly larger?  Is
> > there any real benefit to it nowadays?  Our server set-up is all access
> > must be through the apache user via mod_dav_svn.
> 

Error when merging.

[Gavin "Beau" Baumanis]

Hi There,
I am trying to merge a file from trunk to our production branch.
I am using the following command;
svn merge -r 1:head trunk/qry_report.cfm branches/production/qry_report.cfm 
--accept="theirs-full"

Which is a routine I have followed since starting to use SVN.

However, I am now getting the following error.

svn: '/svn/palcare/!svn/bc/20624/tags/nz/1.5/qry_report.cfm' path not found

I assume, what it saying is;
That the file in trunk has a historical link to a file in tag, but that file at 
that tag location (Or perhaps even the whole tag), no longer exists in the 
repository.
The error is sensible enough

But I am obviously missing something.
How does this effect a merge between a source and destination where the source 
and destination both currently exist?

As always - thanks for any insight.

Gavin.

Re: Size of Subversion repository

[Loren M. Lang]

On Fri, 2011-05-06 at 00:37 +0300, Daniel Shahaf wrote:
> Loren M. Lang wrote on Thu, May 05, 2011 at 14:32:37 -0700:
> > On Thu, 2011-05-05 at 15:43 +0300, Daniel Shahaf wrote:
> > > Loren M. Lang wrote on Wed, May 04, 2011 at 17:39:57 -0700:
> > > > The format file says 3 so I might have made it with 1.3.x.
> > > 
> > > This conclusion is wrong.  The format number is NOT the minor release
> > > number (because we may bump it multiple times between successive minor
> > > lines).
> > 
> > Is there a list of these format numbers and their meanings/features?
> > I'm curious what I missed by not upgrading to 4 when I had the chance.
> > 
> 
> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/fs.h
> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/fs.h
> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure

There appears to be some confusion here.  I was referring to format
under the repository root.  The references you gave me appear to refer
to db/format.  My original 1.4.x repository had format = 3 and db/format
= 1.  When I created the new repositories, format was bumped to 5.  I do
not know what db/format was as I already deleted them, but I'd assume
db/format for the 1.5.x fsfs repository was 3.

My primary question though, was simply whether bdb was normally as
space-inefficient as my test showed and whether I should consider it
over fsfs for Subversion 1.5.x or 1.6.x+.

> 
> > > 
> > 
> > 
> 

Advice:.svn directory should never put in every folder in project

[yn.yyzh]

Advice:.svn directory should never put in every folder in project
Because:a   .svn directory would break the structure of the project file. in
Eclipse, when you build the project, build direcotry would been removed.
This will cause 'obstructed' problem.
Solution: Put only one .svn directory in project home folder. and this
directry contains all other subdirectory as same as the project
Project home /
/folderA
/folderB
   .
-->
   home /
/.svn/
/.svn/folderA
/.svn/folderB
   /folderA
   /folderB
Instead of
   home /
   /.svn/
   /folderA
   /folderA/.svn/
   /folderB
   /folderB/.svn/

Re: Advice:.svn directory should never put in every folder in project

[Ryan Schmidt]

On May 5, 2011, at 22:24, yn.yyzh wrote:

> Advice:.svn directory should never put in every folder in project
> Because:a   .svn directory would break the structure of the project file. in 
> Eclipse, when you build the project, build direcotry would been removed. This 
> will cause 'obstructed' problem.
> Solution: Put only one .svn directory in project home folder. and this 
> directry contains all other subdirectory as same as the project

You have just described what will happen as of Subversion 1.7. If interested, 
you can find more info by searching for "wc-ng" (working copy next generation).

AW: Advice:.svn directory should never put in every folder in project

[Markus Schaber]

Hi, Yn,

 

There are eclipse plugins like Subclipse and Subversive that teach
Eclipse to ignore the .svn subdirectories - I did use them successfully
for several years.

 

Additionally, the build directory should always be marked "svn:ignored",
it is not good style to check temporary directories into the version
repository.

 

And with SVN 1.7, the SVN developers are actually going to change the
working copy format to one central .svn directory in the working copy
root - although with a different internal format than the one you
suggested.

 

Best regards

Markus Schaber

___

We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50

Email: m.scha...@3s-software.com   |
Web: http://www.3s-software.com  
CoDeSys internet forum: http://forum.3s-software.com
 
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects
 

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 

 

Von: yn.yyzh [mailto:yn.y...@gmail.com] 
Gesendet: Freitag, 6. Mai 2011 05:24
An: users@subversion.apache.org
Betreff: Advice:.svn directory should never put in every folder in
project

 

Advice:.svn directory should never put in every folder in project

Because:a   .svn directory would break the structure of the project
file. in Eclipse, when you build the project, build direcotry would been
removed. This will cause 'obstructed' problem.

Solution: Put only one .svn directory in project home folder. and this
directry contains all other subdirectory as same as the project

Project home /

/folderA

/folderB

   .

-->

   home /

/.svn/

/.svn/folderA

/.svn/folderB

   /folderA

   /folderB

Instead of 

   home /

   /.svn/

   /folderA

   /folderA/.svn/

   /folderB

   /folderB/.svn/