details for product

[Shubhangi . Waghmare]

Hello,

We are looking for versioning software.

Request you to please provide  following information about this product.
1. What is licensing policy.(like whether it is licensed, if yes what is
the cost for server and client installation)
2. how it manages centralized repository for code.
3.  does it have any demo version.

Thanks & Regards,
Shubhangi Waghmare
HDFC Bank Ltd.
Desk-30751877
Rim- 9322157595


HDFC Bank has been recognized as "The Strongest Bank in Asia Pacific Region" by 
The Asian Banker, outperforming 59 top tier banks across 13 countries.


Disclaimer:   
"The information contained herein (including any accompanying documents) is 
confidential and is intended solely for the addressee(s). If you have 
erroneously received this message, please immediately delete it and notify the 
sender. Also, if you are not the intended recipient, you are hereby notified 
that any disclosure, copying, distribution or taking any action in reliance on 
the contents of this message or any accompanying document is strictly 
prohibited and is unlawful. The organization is not responsible for any damage 
caused by a virus or alteration of the e-mail by a third party or otherwise. 
The contents of this message may not necessarily represent the views or 
policies of HDFC Bank Ltd."

Re: details for product

[Lorenz]

shubhangi.waghm...@hdfcbank.com wrote:
>We are looking for versioning software.
>
>Request you to please provide  following information about this product.
>1. What is licensing policy.(like whether it is licensed, if yes what is
>the cost for server and client installation)
>2. how it manages centralized repository for code.
>3.  does it have any demo version.

oh come on

have you even looked at http://subversion.apache.org
-- 

Lorenz

Re: Feature request: allow for relative working copy paths in svn:externals definition

[Daniel Shahaf]

Stefan Sperling wrote on Thu, Mar 01, 2012 at 17:27:52 +0100:
> On Thu, Mar 01, 2012 at 04:35:32PM +0100, Humm, Markus wrote:
> > In File
> >  
> > »D:\Development\SVN\Releases\TortoiseSVN-1.7.5\ext\subversion\subversion\libsvn_wc\wc_db.c«,
> >  Zeile 2890: Assert-Anweisung schlug fehl
> >  (svn_dirent_is_ancestor(wcroot->abspath, local_abspath))
> > 
> > The local path of my svn:externals was this: 
> > D:/u/svnexternaltest2/gemeinsamme_bibliotheken
> >
> > If I tried to use ../svnexternaltest2/gemeinsamme_bibliotheken instead 
> > Tortoise would detect that it contains a .. Or is a absolute path. 
> > Obviously either Tortoises or SVN's absolute path detection loginc is not 
> > 100% fool proof as well.
> 
> Yes, this is a bug. Coincidentally this problem was discussed just today.
> See http://svn.haxx.se/users/archive-2012-03/0012.shtml

The assert is a bug, but the error is not.  The code does not permit
either absolute paths or paths containing ".." elements for security
reasons.  (to not allow a malicious server to create files in arbitrary
places in the filesystem --- i.e., not under the wc root)

Re: subversion externals issue

[Daniel Shahaf]

Ryan Schmidt wrote on Thu, Mar 01, 2012 at 08:46:08 -0600:
> 
> On Mar 1, 2012, at 02:59, Neson Maxmelbin (RBEI/EMT4) wrote:
> 
> > I have externals from other repo's configured in my master project under 
> > trunk.
> > When I tag the trunk and then checkout the tag, the externals are not 
> > checked out.
> > When I tag the entire repo and then checkout the tag, the externals are 
> > checked out. Is this the normal behavior? [I tried from Tortoise SVN]
> 
> That does not sound normal to me, and I have not heard of that happening 
> before.
> 
> How is the tag created -- via "svn cp" from the trunk URL, or from a trunk 
> working copy? If from a working copy, is it possible you had not run "svn up" 
> on the working copy since before you added the externals definition?
> 
> If you check out the tag of trunk, does "svn propget svn:externals" show the 
> externals definition or not?
> 
> I don't understand how you would "tag the entire repo" since the tags 
> directory is inside the repo and you cannot copy something into itself.
> 

Sorry Ryan, you're wrong :) 

svnadmin create r1
svn cp file://`pwd`/r1 file://`pwd`/r1 -m "counter example"
svn log -qvr1 file://`pwd`/r1

The catch here is that you copy /@1 into /@2 --- which is not the same
thing.

svn diff on png files

[SravanKumar Sandela]

Hi,

I am using svn 1.7.2 and on doing
"svn diff --diff-cmd -diff abc.png"

i see following output in footer

Property changes on: abc.png
___
Added: svn:mime-type
## -0,0 +1 ##
+image/png

But on previous version of svn (atleast till 1.6.17, r1128011) i see its
footer to be in different format as follows

Property changes on: abc.png
___
Added: svn:mime-type
   + application/octet-stream

Because of this change some of our scripts which do style checking on
patches are failing.

I have few questions,

1. Why are we seeing this change?
2. Is this some buggy or junk character output?
3. Is there a way we can suppress such meta characters?
4. Should we live with it for ever?
5. If this is buggy, has it been already fixed, if not then what does the


## -0,0 +1 ##
+image/png

  mean?

-Sravan.

Re: Subversion for object code

[Helmut Zeisel]

 Original-Nachricht 
> Datum: Thu, 1 Mar 2012 09:07:41 +0200
> Von: Daniel Shahaf 

> Representation sharing works only on complete files.  (If two files are
> not byte-for-byte identical, it never kicks in.)  What you see would be
> the xdelta binary-diff algorithm being efficient.

OK. 

Does this mean that svn uses internally the same algorithm as xdelta 
(http://code.google.com/p/xdelta/)

This would mean that I could directly use 

xdelta3 -s SOURCE TARGET > OUT

to estimate how big the differences between binary files are (without creating 
some svn test repository and measuring repostiory size)

Helmut

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!  

Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

Re: predecessor count for the root node-revision is wrong message

[Daniel Shahaf]

Justin Johnson wrote on Thu, Mar 01, 2012 at 07:45:08 -0600:
> On Wed, Feb 29, 2012 at 4:14 PM, Justin Johnson 
> wrote:
> > On Wed, Feb 29, 2012 at 11:22 AM, Daniel Shahaf  wrote:
> >> ... so please try SVNInMemoryCacheSize 0, and see if that makes the
> >> issue less frequent.
> >>
> >
> > I'm a dork.  I will do so once I take care of the appropriate change
> > control I have to deal with.  Thanks.
> >
> 
> We made the change and problem is still occurring.

OK.  So that means that either membuffer isn't the cause of the error,
or both membuffer and inprocess have (independent) bugs.

That said, I'm happy to see that it took you less than a day to report
that the bug no longer reproduces.  Can you reproduce it at will?

---

I'm not completely sure what to try next.  Were there any other
significant changes in 1.6.x->1.7.x besides caching?  If so, the
next steps would be to disable _both_ inprocess and membuffer, or
to bisect.

Unfortunately, the latter requires building svn from source, and the
former requires either that, or having you upgrade to specially-built
binaries, or squeezing the "disable inprocess" feature into 1.7.4 (in
a way that doesn't break our compat policy too badly) and having you
upgrade to that.

devs/all --- thoughts?  Is there a simpler way forward than the two
potential 'next step's I've outlined here?

Re: details for product

[Jeyanthan]

On Friday 02 March 2012 01:29 PM, shubhangi.waghm...@hdfcbank.com wrote:

Hello,

We are looking for versioning software.

Request you to please provide following information about this product.
1. What is licensing policy.(like whether it is licensed, if yes what is
the cost for server and client installation)
2. how it manages centralized repository for code.
3. does it have any demo version.


You have reached the right forum. Subversion is an open source / free 
software and is the best centralized version control system software 
amongst all the other VC's available in the market.


Subversion carries an Apache License - 
http://www.apache.org/licenses/LICENSE-2.0


Below are Subversion training videos you might like to watch to know 
more about Subversion..


http://www.open.collab.net/community/subversion/training.html

For Support, visit 
http://www.open.collab.net/support/support-programs/subversion.html


As Subversion is completely open source, you get the entire software for 
free and there is no 'Demo' version..


For more info,visit here http://www.open.collab.net/products/subversion/

--
Regards,
Jeyanthan

Re: svn diff on png files

[Philip Martin]

SravanKumar Sandela  writes:

> 5. If this is buggy, has it been already fixed, if not then what does the
>
>
> ## -0,0 +1 ##
> +image/png
>
>   mean?

It's intentional, 1.7 shows property diffs as unified diffs:

http://subversion.apache.org/docs/release-notes/1.7.html#diff-properties

-- 
Philip

Re: Subversion for object code

[Daniel Shahaf]

Helmut Zeisel wrote on Fri, Mar 02, 2012 at 10:28:16 +0100:
> 
>  Original-Nachricht 
> > Datum: Thu, 1 Mar 2012 09:07:41 +0200
> > Von: Daniel Shahaf 
> 
> > Representation sharing works only on complete files.  (If two files are
> > not byte-for-byte identical, it never kicks in.)  What you see would be
> > the xdelta binary-diff algorithm being efficient.
> 
> OK. 
> 
> Does this mean that svn uses internally the same algorithm as xdelta 
> (http://code.google.com/p/xdelta/)
> 

I don't know offhand how close our implementation is to other
implementations or to research papers.  There are some comments in
subversion/libsvn_delta/xdelta.c (lines 35 and 370) that suggest some
divergence from other sources.

CC'ing dev@ so people who know this code better can join the
conversation.

> This would mean that I could directly use 
> 
> xdelta3 -s SOURCE TARGET > OUT
> 
> to estimate how big the differences between binary files are (without 
> creating some svn test repository and measuring repostiory size)
> 
> Helmut
> 
> -- 
> NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
>   
> Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

Re: predecessor count for the root node-revision is wrong message

[Daniel Shahaf]

Daniel Shahaf wrote on Wed, Feb 29, 2012 at 18:15:41 +0200:
> Justin, Jason,
> 
> Some things you could do are:
> 
> - What RA method do you use?  svn:// or http://?
> 

Justin, what operating system does your server run?

Re: predecessor count for the root node-revision is wrong message

[Daniel Shahaf]

Jason Wong wrote on Thu, Mar 01, 2012 at 10:01:26 -0800:
> I have had a developer here create a build of the latest SVN code
> with your changes you mentioned in r1294470 for the svnadmin verify

Okay, that's great news, for two reasons:

1. It means building svn on windows isn't as painful as it used to be :)

2. It means I can ask you to build a custom server with the 'inprocess'
cache disabled, or (if all else fails) to bisect, per my previous email.

One of the things you could try is to disable caching: simply modify
the function create_cache() in libsvn_fs_fs/caching.c to always return
NULL in *CACHE_P.  See below for another suggestion.

> command. We have run 'svnadmin verify' against every revision of our
> hotcopy of our repository taken when we first brought this issue to
> the forums and are now tracking down each of the revisions to see
> what actions were being done at those times.
> 

Thanks!  I do hope this work enables us to pinpoint and fix the bug.

> From the results, we see 25 error messages for predecessor count is
> wrong and the first one appeared on January 26, 2011. Near that time
> the following events occurred:
>Jan. 14, 2011 - svn upgraded from 1.6.6 to 1.6.15
>Jan. 14, 2011 - Apache HTTP server upgraded from 2.2.15 to 2.2.17
>Jan. 21, 2011 - repository was pruned to delete some binary files.
>   
> Between January and our upgrade in Dec. to 1.7.1, we have had about
> 14,000 revisions and seen only 25 instances of this node revision
> issue. During the times we had these errors, we were using svn
> versions 1.6.15 and 1.6.16.
> 

Thanks, very valuable information.

I've reviewed the 1.6.6->1.6.15 diff, and I have the following
suggestions:

- Change subversion/libsvn_fs_fs/fs.h such that
  SVN_FS_FS__USE_LOCK_MUTEX is set to 1.  It was set to 1 in 1.6.6
  but to 0 in 1.6.15.

  (This wouldn't explain why ASF saw it, but it might explain why you're
  seeing it.)

> Fail2ban from what I could find does not look like it has a Windows
> port which I currently have my production environment hosted on.
> 

Yeah, sorry.  But you can write a cron job -- I mean, a Scheduled Task
-- that greps your error logs for "160004" every night and mails you it
it found anything, right?

That's the error code to watch for for many FS error conditions:
% ./tools/dev/which-error.py E160004
00160004  SVN_ERR_FS_CORRUPT

> Thanks.
> 
> Jason

For convenience I'm attaching a patch that implements both of my
suggestions.  Let us know please if it has any effect.

Cheers,

Daniel

Index: subversion/libsvn_fs_fs/fs.h
===
--- subversion/libsvn_fs_fs/fs.h	(revision 1295418)
+++ subversion/libsvn_fs_fs/fs.h	(working copy)
@@ -161,7 +161,7 @@ typedef struct fs_fs_shared_txn_data_t
per file.  On Windows apr implements the locking as per file handle
locks, so we don't have to add our own mutex for just in-process
synchronization. */
-#if APR_HAS_THREADS && !defined(WIN32)
+#if APR_HAS_THREADS /* disabled: and !defined(WIN32) */
 #define SVN_FS_FS__USE_LOCK_MUTEX 1
 #else
 #define SVN_FS_FS__USE_LOCK_MUTEX 0
Index: subversion/libsvn_fs_fs/caching.c
===
--- subversion/libsvn_fs_fs/caching.c	(revision 1295418)
+++ subversion/libsvn_fs_fs/caching.c	(working copy)
@@ -209,6 +209,9 @@ create_cache(svn_cache__t **cache_p,
  const char *prefix,
  apr_pool_t *pool)
 {
+  *cache_p = NULL;
+  return SVN_NO_ERROR;
+
 if (memcache)
   {
 SVN_ERR(svn_cache__create_memcache(cache_p, memcache,

AW: Feature request: allow for relative working copy paths in svn:externals definition

[Humm, Markus]

Hello,

thanks for your answer.

While it is nice that you have concerns about my security in case I should have 
to deal with malicious servers,
I would prefer to have a choice. Maybe some setting wich allows me, based on 
the server URL (or if that's too 
complicated for a start), to allow ../ in local externals paths or disallow 
this. With such a setting, SVN would
seamlessly allow us to use our current directory layout while maintaining the 
benefits of atimic checkins.

A colleague of mine who uses a similiar directory layout and currently uses CVS 
and would have to switch when our
SVN rollout happens now claimed that CVS supports this way of working 
(directory structure). If I'm not mistaken
SVN uses the claim "CVS done right". So it should support this, as this is a 
legitimate directory structure
And imposes no security problems in secure environments (eg. Our campus LAN 
with out local SVN server I administer).

What do I need to do to get this feature? Where do I need to lobby for it?

Best regards

Markus Humm

EB-EV
Entwicklung Elektronik

ebm-papst Mulfingen GmbH & Co. KG
Bachmühle 2
74673 Mulfingen

Phone.: +49 (7938) 81 531
Fax: +49 (7938) 81 9531
mailto: markus.h...@de.ebmpapst.com
http://www.ebmpapst.com

GreenTech - Ein Zeichen, mit dem wir Zeichen setzen. A symbol that defines 
standards.

-Ursprüngliche Nachricht-
Von: Daniel Shahaf [mailto:danie...@elego.de] 
Gesendet: Freitag, 2. März 2012 10:23
An: Humm, Markus
Cc: users@subversion.apache.org
Betreff: Re: Feature request: allow for relative working copy paths in 
svn:externals definition

Stefan Sperling wrote on Thu, Mar 01, 2012 at 17:27:52 +0100:
> On Thu, Mar 01, 2012 at 04:35:32PM +0100, Humm, Markus wrote:
> > In File
> >  
> > »D:\Development\SVN\Releases\TortoiseSVN-1.7.5\ext\subversion\subver
> > sion\libsvn_wc\wc_db.c«,  Zeile 2890: Assert-Anweisung schlug fehl  
> > (svn_dirent_is_ancestor(wcroot->abspath, local_abspath))
> > 
> > The local path of my svn:externals was this: 
> > D:/u/svnexternaltest2/gemeinsamme_bibliotheken
> >
> > If I tried to use ../svnexternaltest2/gemeinsamme_bibliotheken instead 
> > Tortoise would detect that it contains a .. Or is a absolute path. 
> > Obviously either Tortoises or SVN's absolute path detection loginc is not 
> > 100% fool proof as well.
> 
> Yes, this is a bug. Coincidentally this problem was discussed just today.
> See http://svn.haxx.se/users/archive-2012-03/0012.shtml

The assert is a bug, but the error is not.  The code does not permit either 
absolute paths or paths containing ".." elements for security reasons.  (to not 
allow a malicious server to create files in arbitrary places in the filesystem 
--- i.e., not under the wc root)


ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart 
HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter 
Fuchs, Dr. Bruno Lindl, Thomas Wagner

Subversion multi-Project Repository: how to?

[Pietro Moras]

Very well, 
   now I dare ask the same question not in point of principle, but with a 
practical, operative purpose. IF multi-project Repository is really possible, 
HOW can be it done, in practice? 
I mean: 
1]  Is it done through the creation of a sub-Repository, at Server level, care 
of “svnadmin.exe”? How? Using what command?

2]  Is it done through a special creation of a single Project, at Client level, 
care of “svn.exe” [or, if that IDE case, some Eric VC command]? Through which 
command, exactly?

3]  Is there a way to select the desired Project, exclusively, both for 
up-loading and down-loading data, without being bothered by the possible 
presence of other similar and distinct Projects, within the same Repository? 
How, exactly? With which “svn.exe” [or, if that IDE case, some Eric VC] 
commands?
 It might be my fault, but what I've seen so far about this matter spans from 
utterly impractical to impossible, hence my stated questions. Gratefully, yours
 - P.M.   

Re: Subversion multi-Project Repository: how to?

[Ulrich Eckhardt]

Am 02.03.2012 12:23, schrieb Pietro Moras:

Very well, now I dare ask the same question not in point of
principle, but with a practical, operative purpose. IF multi-project
Repository is really possible, HOW can be it done, in practice?


Subversion doesn't define the term "project". This term can have lots of 
different meanings, depending on the context. Subversion provides 
versioned storage of file trees plus a few additional small features, 
but that is all.




> 1]  Is it done through the creation of a sub-Repository, at
> Server level, care of “svnadmin.exe”? How? Using what command?

There are no nested repositories, every repository is its own universe 
without any dependencies on other repos. What you mean is directories 
inside a repository perhaps.




3]  Is there a way to select the desired Project, exclusively, both
for up-loading and down-loading data, without being bothered by the
possible presence of other similar and distinct Projects, within the
same Repository?


You can create a working copy (make sure you understand this term!) 
which only contains a subset of the repository it is associated with. 
This is the usual case, btw.



I think what you need to look at is the documentation explaining the 
idea behind the customary trunk/branches/tags layout. There you will 
also find a suggestion where to place that what is often considered as a 
project in this hierarchy. Also, make sure you understand both the scope 
(i.e. that SVN doesn't know what you consider a project) and 
terminology. Otherwise it's a bit difficult to communicate, if two 
people attach different meanings to the same term.



Cheers!

Uli

**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: Feature request: allow for relative working copy paths in svn:externals definition

[Daniel Shahaf]

Humm, Markus wrote on Fri, Mar 02, 2012 at 12:13:28 +0100:
> Hello,
> 
> thanks for your answer.
> 
> While it is nice that you have concerns about my security in case
> I should have to deal with malicious servers, I would prefer to have
> a choice. Maybe some setting wich allows me, based on the server URL
> (or if that's too complicated for a start), to allow ../ in local

I agree.  While the default should be to disallow any modifications
above the working copy root, I don't see a reason not to make it an
opt-in feature.

> What do I need to do to get this feature? Where do I need to lobby for
> it?

The best thing you could do is head over to the dev@ list, drive
a design discussion, get consensus on it, and ideally also be willing
to implement it (or to hire someone to do so):

http://subversion.apache.org/contributing#code-design

Alternatively, you could record your request in our issue tracker:

http://subversion.apache.org/reporting-issues.html

Re: Feature request: allow for relative working copy paths in svn:externals definition

[Nico Kadel-Garcia]

On Fri, Mar 2, 2012 at 6:13 AM, Humm, Markus wrote:

> Hello,
>
> thanks for your answer.
>
> While it is nice that you have concerns about my security in case I should
> have to deal with malicious servers,
> I would prefer to have a choice. Maybe some setting wich allows me, based
> on the server URL (or if that's too
> complicated for a start), to allow ../ in local externals paths or
> disallow this. With such a setting, SVN would
> seamlessly allow us to use our current directory layout while maintaining
> the benefits of atimic checkins.
>
> Excuse me, but given the layout requirements you seek, can you get away
with symlinks?

There are too many cases where non-root users have access to Subversion
repositories for repositories that get run by, and manipulated by, the root
user. The possibility of escalation attacks for *other* environments seems
very large.



> A colleague of mine who uses a similiar directory layout and currently
> uses CVS and would have to switch when our
> SVN rollout happens now claimed that CVS supports this way of working
> (directory structure). If I'm not mistaken
> SVN uses the claim "CVS done right". So it should support this, as this is
> a legitimate directory structure
> And imposes no security problems in secure environments (eg. Our campus
> LAN with out local SVN server I administer).
>

Then write your own patch to disable the checks. For general deployment, I
think it's begging for escalation attacks.

What do I need to do to get this feature? Where do I need to lobby for it?
>

I'm an old user, not a core developer, but this would seem to be a good
place for general discussion  I can see the escalation attacks in a more
general environment, myself: I see too many places in environments where I
work that an *accidental* such use could cause endless havoc by
pre-populating a system directory, such as, say, /etc/nagios.

Re: predecessor count for the root node-revision is wrong message

[Daniel Shahaf]

Daniel Shahaf wrote on Fri, Mar 02, 2012 at 12:21:46 +0200:
> Daniel Shahaf wrote on Wed, Feb 29, 2012 at 18:15:41 +0200:
> > Justin, Jason,
> > 
> > Some things you could do are:
> > 
> > - What RA method do you use?  svn:// or http://?
> > 
> 
> Justin, what operating system does your server run?
> 

... and what versions of httpd (Apache) and APR.

Re: details for product

[Nico Kadel-Garcia]

On Fri, Mar 2, 2012 at 4:43 AM, Jeyanthan  wrote:

>
> On Friday 02 March 2012 01:29 PM, 
> Shubhangi.Waghmare@hdfcbank.**comwrote:
>
>> Hello,
>>
>> We are looking for versioning software.
>>
>> Request you to please provide following information about this product.
>> 1. What is licensing policy.(like whether it is licensed, if yes what is
>> the cost for server and client installation)
>> 2. how it manages centralized repository for code.
>> 3. does it have any demo version.
>>
>
> Jeyanthan's comments below are very good. They don't mention the issues of
a completely centralized system such as Subversion, which is that laptop or
remote users cannot record changes locally without being connected to the
centralized system. Subversion is also very popular and relatively easy to
learn. Perhaps you could describe what you're attempting to achieve, and
contact a company like Wandisco if you need to integrate a new corporate
grade centralized setup? They have good high availability and backup
toolkits, and are leading development, so if you need corporate grade
support I'd definitely give them a call.

A demo is trivial to set up with the existing free and open sourced
binaries for evey major operating system. If you have *old* operating
systems you need to support with the latest features, you may have a
problem, but this is true of every modern source control system.

Nico Kadel-Garcia


> You have reached the right forum. Subversion is an open source / free
> software and is the best centralized version control system software
> amongst all the other VC's available in the market.
>
> Subversion carries an Apache License - http://www.apache.org/**
> licenses/LICENSE-2.0 
>
> Below are Subversion training videos you might like to watch to know more
> about Subversion..
>
> http://www.open.collab.net/**community/subversion/training.**html
>
> For Support, visit http://www.open.collab.net/**support/support-programs/*
> *subversion.html
>
> As Subversion is completely open source, you get the entire software for
> free and there is no 'Demo' version..
>
> For more info,visit here 
> http://www.open.collab.net/**products/subversion/
>
> --
> Regards,
> Jeyanthan
>

AW: Feature request: allow for relative working copy paths in svn:externals definition

[Humm, Markus]

Hello,
 
> > While it is nice that you have concerns about my security in case I should 
> > have to deal with malicious servers,
> > I would prefer to have a choice. Maybe some setting wich allows me, based 
> > on the server URL (or if that's too
> > complicated for a start), to allow ../ in local externals paths or disallow 
> > this. With such a setting, SVN would
> > seamlessly allow us to use our current directory layout while maintaining 
> > the benefits of atimic checkins.

> Excuse me, but given the layout requirements you seek, can you get away with 
> symlinks?

I'm not sure symlinks under XP are powerfull enough and the use of them is not 
easy enough for my colloeagues.
I'd really prefer a externals based solution.

> There are too many cases where non-root users have access to Subversion 
> repositories for repositories that 
> get run by, and manipulated by, the root user. The possibility of escalation 
> attacks for *other* environments seems very large.

That is why I suggested a setting controlling this. The default could be to 
disallow it. You can misuse nearly 
everything! So nearly everything in the world should be disallowed. I also 
suggested that limiting this relative addressing
to a single level in the hierarchy (means only ../ instead of ../../) would be 
sufficient for must users and still keeping
a good deal of the security. And if you could enable this for individual 
"domains" only one can still limit it for local 
servers only. If properly implemented it will only do good for those needing it 
and no harm (unless misconfigured, but
that can be said for most configuration options in most software...)

=> I'll request that on the developer mailing list as suggested.

Best regards 

Markus Humm 

EB-EV
Entwicklung Elektronik 

ebm-papst Mulfingen GmbH & Co. KG
Bachmühle 2
74673 Mulfingen 

Phone: +49 (7938) 81 531
Fax: +49 (7938) 81 9531
markus.h...@de.ebmpapst.com  
http://www.ebmpapst.com   


GreenTech -   Ein Zeichen, mit dem wir Zeichen setzen. A 
symbol that defines standards. 

 




Von: Nico Kadel-Garcia [mailto:nka...@gmail.com] 
Gesendet: Freitag, 2. März 2012 13:13
An: Humm, Markus
Cc: Daniel Shahaf; users@subversion.apache.org
Betreff: Re: Feature request: allow for relative working copy paths in 
svn:externals definition





On Fri, Mar 2, 2012 at 6:13 AM, Humm, Markus  
wrote:


Hello,

thanks for your answer.

While it is nice that you have concerns about my security in case I 
should have to deal with malicious servers,
I would prefer to have a choice. Maybe some setting wich allows me, 
based on the server URL (or if that's too
complicated for a start), to allow ../ in local externals paths or 
disallow this. With such a setting, SVN would
seamlessly allow us to use our current directory layout while 
maintaining the benefits of atimic checkins.



Excuse me, but given the layout requirements you seek, can you get away with 
symlinks?

There are too many cases where non-root users have access to Subversion 
repositories for repositories that get run by, and manipulated by, the root 
user. The possibility of escalation attacks for *other* environments seems very 
large.

 

A colleague of mine who uses a similiar directory layout and currently 
uses CVS and would have to switch when our
SVN rollout happens now claimed that CVS supports this way of working 
(directory structure). If I'm not mistaken
SVN uses the claim "CVS done right". So it should support this, as this 
is a legitimate directory structure
And imposes no security problems in secure environments (eg. Our campus 
LAN with out local SVN server I administer).



Then write your own patch to disable the checks. For general deployment, I 
think it's begging for escalation attacks. 



What do I need to do to get this feature? Where do I need to lobby for 
it?



I'm an old user, not a core developer, but this would seem to be a good place 
for general discussion  I can see the escalation attacks in a more general 
environment, myself: I see too many places in environments where I work that an 
*accidental* such use could cause endless havoc by pre-populating a system 
directory, such as, say, /etc/nagios.




ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart 
HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter 
Fuchs, Dr. Bruno Lindl, Thomas Wagner

Re: Feature request: allow for relative working copy paths in svn:externals definition

[Les Mikesell]

On Fri, Mar 2, 2012 at 6:58 AM, Humm, Markus
 wrote:
>
>> > While it is nice that you have concerns about my security in case I should 
>> > have to deal with malicious servers,

Not just malicious servers.  With a scheme that lets you splatter
files anywhere, anyone who can commit can accidentally or
intentionally kill everyone else's machines.

>> > I would prefer to have a choice. Maybe some setting wich allows me, based 
>> > on the server URL (or if that's too
>> > complicated for a start), to allow ../ in local externals paths or 
>> > disallow this. With such a setting, SVN would
>> > seamlessly allow us to use our current directory layout while maintaining 
>> > the benefits of atimic checkins.
>
>> Excuse me, but given the layout requirements you seek, can you get away with 
>> symlinks?
>
> I'm not sure symlinks under XP are powerfull enough and the use of them is 
> not easy enough for my colloeagues.
> I'd really prefer a externals based solution.

And these people are going to be able to figure out what happened when
critical OS or personal files are overwritten?  On an OS that won't
prevent it?

> That is why I suggested a setting controlling this. The default could be to 
> disallow it. You can misuse nearly
> everything! So nearly everything in the world should be disallowed. I also 
> suggested that limiting this relative addressing
> to a single level in the hierarchy (means only ../ instead of ../../) would 
> be sufficient for must users and still keeping
> a good deal of the security. And if you could enable this for individual 
> "domains" only one can still limit it for local
> servers only. If properly implemented it will only do good for those needing 
> it and no harm (unless misconfigured, but
> that can be said for most configuration options in most software...)

What is wrong with keeping everything under one tree?   If you are too
lazy to re-arrange the paths for includes and linkage searches in your
compiler project/build files, treat each thing that you want in
parallel directories as a component and make your subversion main
project files have nothing but the externals that drop the components
in the right place - which incidentally gives you a nice single place
to control the branch/tag versions of each thing that you use.

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

Re: Feature request: allow for relative working copy paths in svn:externals definition

[Andy Levy]

On Fri, Mar 2, 2012 at 07:58, Humm, Markus  wrote:
> Hello,
>
>> > While it is nice that you have concerns about my security in case I should 
>> > have to deal with malicious servers,
>> > I would prefer to have a choice. Maybe some setting wich allows me, based 
>> > on the server URL (or if that's too
>> > complicated for a start), to allow ../ in local externals paths or 
>> > disallow this. With such a setting, SVN would
>> > seamlessly allow us to use our current directory layout while maintaining 
>> > the benefits of atimic checkins.
>
>> Excuse me, but given the layout requirements you seek, can you get away with 
>> symlinks?
>
> I'm not sure symlinks under XP are powerfull enough and the use of them is 
> not easy enough for my colloeagues.
> I'd really prefer a externals based solution.

True symlinks don't even exist on XP.

AW: Feature request: allow for relative working copy paths in svn:externals definition

[Humm, Markus]

Hello,

>>
>>> > While it is nice that you have concerns about my security in case
I 
>>> > should have to deal with malicious servers,
>
> Not just malicious servers.  With a scheme that lets you splatter
files anywhere, anyone who can commit can accidentally or intentionally
kill everyone else's machines.

While I can see your security concerns my intention is to use this
feature only in conjunction with locally hosted servers
(same company, same site, all users know each others) and only a single
hierarchy level deep. I already suggested to limit 
this to a single hierarchy level.

>>> > I would prefer to have a choice. Maybe some setting wich allows
me, 
>>> > based on the server URL (or if that's too complicated for a
start), 
>>> > to allow ../ in local externals paths or disallow this. With such
a setting, SVN would seamlessly allow us to use our current directory
layout while maintaining the benefits of atimic checkins.
>>
>>> Excuse me, but given the layout requirements you seek, can you get
away with symlinks?
>>
>> I'm not sure symlinks under XP are powerfull enough and the use of
them is not easy enough for my colloeagues.
>> I'd really prefer a externals based solution.
> What is wrong with keeping everything under one tree?   If you are too
> lazy to re-arrange the paths for includes and linkage searches in your
compiler project/build files, treat each thing that you want in parallel
directories as a component and make your subversion main project files
have nothing but > the externals that drop the components in the right
place - which incidentally gives you a nice single place to control the
branch/tag versions of each thing that you use.

Because keeping everything under one tree ties things together wich do
not have any relation other than via CommonFiles.
In my eyes nothing beats the simplicity and understandability of
svn:externals with one single level deep relative paths 
to a directory above. Software should adopt as good as possible to the
existing workflow/structures. There should be no
need to completely rearrange projects just to get what one wants only
because some fear security issues which can be 
turned off with a single global "turn this feature off" switch in the
client. Those who like can use it, the rest can 
ignore it as the default would be to have it off.

Best regards

Markus Humm


ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart 
HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter 
Fuchs, Dr. Bruno Lindl, Thomas Wagner

Re: details for product

[Les Mikesell]

On Fri, Mar 2, 2012 at 6:30 AM, Nico Kadel-Garcia  wrote:
>
>>
> Jeyanthan's comments below are very good. They don't mention the issues of a
> completely centralized system such as Subversion, which is that laptop or
> remote users cannot record changes locally without being connected to the
> centralized system.

Someone who hasn't used subversion might misunderstand that.  You can
check out a working copy, disconnect and make changes -  and even do a
limited set of versioning operations like diffs against the checked
out version while offline.   The main limitation is that you can't
commit multiple versions while offline  and you can only revert local
changes back to the checked out version - you only have the one copy
of the workspace and can't commit the changes in it until you can
connect back to the repository.

> A demo is trivial to set up with the existing free and open sourced binaries
> for evey major operating system. If you have *old* operating systems you
> need to support with the latest features, you may have a problem, but this
> is true of every modern source control system.

The main downside of free software is that you don't get a salesperson
to buy your lunch while showing you nice glossy pictures of the
product.

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

Re: Feature request: allow for relative working copy paths in svn:externals definition

[Thorsten Schöning]

Guten Tag Andy Levy,
am Freitag, 2. März 2012 um 14:45 schrieben Sie:

> True symlinks don't even exist on XP.

But XP has junctions/reparse points which would be just as good as
symlinks on directory level as in this case needed. Creatable with
fsutils(?) and Sysinternals' junction.exe, which I would prefer.

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.030-2 1001-310
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

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

Re: predecessor count for the root node-revision is wrong message

[Justin Johnson]

On Fri, Mar 2, 2012 at 3:41 AM, Daniel Shahaf  wrote:

> Justin Johnson wrote on Thu, Mar 01, 2012 at 07:45:08 -0600:
> > On Wed, Feb 29, 2012 at 4:14 PM, Justin Johnson <
> justinandto...@gmail.com>wrote:
> > > On Wed, Feb 29, 2012 at 11:22 AM, Daniel Shahaf 
> wrote:
> > >> ... so please try SVNInMemoryCacheSize 0, and see if that makes the
> > >> issue less frequent.
> > >>
> > >
> > > I'm a dork.  I will do so once I take care of the appropriate change
> > > control I have to deal with.  Thanks.
> > >
> >
> > We made the change and problem is still occurring.
>
> OK.  So that means that either membuffer isn't the cause of the error,
> or both membuffer and inprocess have (independent) bugs.
>
> That said, I'm happy to see that it took you less than a day to report
> that the bug no longer reproduces.  Can you reproduce it at will?
>
>
No, but our server has about 2500 active users on it, so it doesn't take
long to see errors.  If we make a configuration change and a day goes by
without the error showing up in the logs I would suspect the problem was
fixed.  If a week were to pass with no error I would feel much more
confident.

Yesterday had 6 of the errors and 1 today so far.

Re: Feature request: allow for relative working copy paths in svn:externals definition

[Les Mikesell]

On Fri, Mar 2, 2012 at 7:54 AM, Humm, Markus
 wrote:
>>
>> Not just malicious servers.  With a scheme that lets you splatter
> files anywhere, anyone who can commit can accidentally or intentionally
> kill everyone else's machines.
>
> While I can see your security concerns my intention is to use this
> feature only in conjunction with locally hosted servers
> (same company, same site, all users know each others) and only a single
> hierarchy level deep. I already suggested to limit
> this to a single hierarchy level.

Which would need to permit the external part to do the same to be
useful.  So you could keep going up.

>> What is wrong with keeping everything under one tree?   If you are too
>> lazy to re-arrange the paths for includes and linkage searches in your
> compiler project/build files, treat each thing that you want in parallel
> directories as a component and make your subversion main project files
> have nothing but > the externals that drop the components in the right
> place - which incidentally gives you a nice single place to control the
> branch/tag versions of each thing that you use.
>
> Because keeping everything under one tree ties things together wich do
> not have any relation other than via CommonFiles.

Then commit a tree that includes things the way you want.  Or if they
really have no relationship, check them out separately.

> In my eyes nothing beats the simplicity and understandability of
> svn:externals with one single level deep relative paths
> to a directory above.

And in my eyes that is insanely dangerous.

> Software should adopt as good as possible to the
> existing workflow/structures. There should be no
> need to completely rearrange projects just to get what one wants only
> because some fear security issues which can be
> turned off with a single global "turn this feature off" switch in the
> client. Those who like can use it, the rest can
> ignore it as the default would be to have it off.

You don't have to re-arrange anything (even if your arrangement
doesn't make any sense...).  You just need to commit a project at the
top level that puts your components at the relative positions below
where you want them.

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

Re: predecessor count for the root node-revision is wrong message

[Justin Johnson]

On Fri, Mar 2, 2012 at 6:21 AM, Daniel Shahaf  wrote:

> Daniel Shahaf wrote on Fri, Mar 02, 2012 at 12:21:46 +0200:
> > Daniel Shahaf wrote on Wed, Feb 29, 2012 at 18:15:41 +0200:
> > > Justin, Jason,
> > >
> > > Some things you could do are:
> > >
> > > - What RA method do you use?  svn:// or http://?
> > >
> >
> > Justin, what operating system does your server run?
> >
>
> ... and what versions of httpd (Apache) and APR.
>

Solaris 10
apr 1.4.5
httpd 2.2.19

Re: Feature request: allow for relative working copy paths in svn:externals definition

[Andreas Krey]

On Fri, 02 Mar 2012 14:54:38 +, Humm, Markus wrote:
...
> In my eyes nothing beats the simplicity and understandability of
> svn:externals with one single level deep relative paths 
> to a directory above.

Exactly as long as you don't try to do

   svn checkout http://your/soft/ware/trunk dir-a
   svn checkout http://your/soft/ware/trunk dir-b

in one and the same directory (namely $HOME, where I do this all the
time).

> Software should adopt as good as possible to the
> existing workflow/structures. There should be no
> need to completely rearrange projects just to get what one wants only

'completely rearrange' is a bit harsh for putting the CommonFiles
external within instead of besides the tree checked out. Besides,
the very idea of letting a checkout/clone create files outside
of the target directory I specified is foreign to all other version
control systems I used so far.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

SVN 1.7.X Comparison

[Waseem Shahzad]

Guys

Can anyone share the difference between 1.7 to all 

 

1.7.1

1.7.2

1.7.3  and all.

 

Versions of SVN.

 

Cheers, 

Waseem Bukhari

CMer - Ext: 506

 

AW: SVN 1.7.X Comparison

[Markus Schaber]

Hi, Waseem,

They are already shared, see the release notes and announcements, and, if 
you're into detail, the publicly available svn log of the 1.7 branch.

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: Waseem Shahzad [mailto:waseem.shah...@curemd.com]
Gesendet: Freitag, 2. März 2012 15:33
An: users@subversion.apache.org
Betreff: SVN 1.7.X Comparison

Guys
Can anyone share the difference between 1.7 to all

1.7.1
1.7.2
1.7.3  and all.

Versions of SVN.

Cheers,
Waseem Bukhari
CMer - Ext: 506

Re: Feature request: allow for relative working copy paths in svn:externals definition

[Les Mikesell]

On Fri, Mar 2, 2012 at 8:14 AM, Andreas Krey  wrote:
> On Fri, 02 Mar 2012 14:54:38 +, Humm, Markus wrote:
> ...
>> In my eyes nothing beats the simplicity and understandability of
>> svn:externals with one single level deep relative paths
>> to a directory above.
>
> Exactly as long as you don't try to do
>
>   svn checkout http://your/soft/ware/trunk dir-a
>   svn checkout http://your/soft/ware/trunk dir-b
>
> in one and the same directory (namely $HOME, where I do this all the
> time).
>

I got the impression that he wants that to work with a single copy of
his commonlib pulled into the parallel directory like he had checked
it out there separately.  But, that misses the point of versioning.
It is common practice for the externals to be tied to specific
branch/tag or peg revisions, and also common in development for one
project to require libs at a different version than another.So,
even if you ignore the danger to non-svn files, the workspaces have to
be self-contained to protect them from each other.

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

AW: Feature request: allow for relative working copy paths in svn:externals definition

[Humm, Markus]

Hello, 

We tried a solution with junctions now (using a sysinternals junction
tool which works under XP already).
Server side in the repository all is well, but in the working copy it
doesn't work as intended as Tortoise SVN
gives us a faliure messaage on our checkin.

What did we do?

We have this structure:
D:\Test\Projekt1
D:\Test\Common

We created a Junction inside D:\Test\Projekt1 named
D:\Test\Projekt1\JunctionTest which points to
D:\Test\Common

so D:\Test\Projekt1\JunctionTest does exist as a hard link. Everything
you insert there
will turn up in D:\Test\Common and vice versa. Works fine with Windows.

Now we created some folders on the server:

/Projekt1/trunc
/Common/trunc

We defined a svn:externals on D:\Test\Projekt1 with these parameters:
Local directory is JunctionTest and URL on the server points to
/Common/trunc

Tortoise SVN accepted that.

We added everything below Projekt1 except JunctionTest to the repository
which worked fine
as the repro browser clearly shows.

We separately added everything from Common to the repository so it went
to /Common/trunc

In the repository (repro browser) we can see now that JunctionTest links
to /Common/trunk

But in the working copy we cannot get this to work. A commit on Projekt1
via Tortoise SVN 
doesn't take the externals into account and a update on Projekt1 ends in
a failure message:
(translated from german)
Externals failed d:\Test\Projekt1\JunctionTest
Failure d:\Test\Projekt1\JunctionTest already exists and is no directory


Best regards

Markus Humm


ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart 
HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter 
Fuchs, Dr. Bruno Lindl, Thomas Wagner

Re: predecessor count for the root node-revision is wrong message

[Jason Wong]

On Fri, Mar 2, 2012 at 2:58 AM, Daniel Shahaf  wrote:
> Jason Wong wrote on Thu, Mar 01, 2012 at 10:01:26 -0800:
>> I have had a developer here create a build of the latest SVN code
>> with your changes you mentioned in r1294470 for the svnadmin verify
>
> Okay, that's great news, for two reasons:
>
> 1. It means building svn on windows isn't as painful as it used to be :)

Actually, it did take some work to get it going as we did not have
another system available to us and also did not have VC++ 6. We had
to use VS 2010 in order to do this. Also, for the other components
required (python,perl etc), the files after the install were copied
to the workstation to see if it would work as we did not want to
change the current workstation configuration by running the
installers. All in all, it did seem to work.

>
> 2. It means I can ask you to build a custom server with the 'inprocess'
> cache disabled, or (if all else fails) to bisect, per my previous email.
>
> One of the things you could try is to disable caching: simply modify
> the function create_cache() in libsvn_fs_fs/caching.c to always return
> NULL in *CACHE_P.  See below for another suggestion.
>
>> command. We have run 'svnadmin verify' against every revision of our
>> hotcopy of our repository taken when we first brought this issue to
>> the forums and are now tracking down each of the revisions to see
>> what actions were being done at those times.
>>
>
> Thanks!  I do hope this work enables us to pinpoint and fix the bug.

I will be going through the list to see what else was happening at the
same time on the apache server since it was alluded to that there may
be concurrency issues. I know the last two times that this error has
popped up, we had two svn operations starting at around the same time
according to the Apache logs. I will go through the previous apache
history to see if this was always the case or not.

>
>> From the results, we see 25 error messages for predecessor count is
>> wrong and the first one appeared on January 26, 2011. Near that time
>> the following events occurred:
>>Jan. 14, 2011 - svn upgraded from 1.6.6 to 1.6.15
>>Jan. 14, 2011 - Apache HTTP server upgraded from 2.2.15 to 2.2.17
>>Jan. 21, 2011 - repository was pruned to delete some binary files.
>>
>> Between January and our upgrade in Dec. to 1.7.1, we have had about
>> 14,000 revisions and seen only 25 instances of this node revision
>> issue. During the times we had these errors, we were using svn
>> versions 1.6.15 and 1.6.16.
>>
>
> Thanks, very valuable information.
>
> I've reviewed the 1.6.6->1.6.15 diff, and I have the following
> suggestions:
>
> - Change subversion/libsvn_fs_fs/fs.h such that
>  SVN_FS_FS__USE_LOCK_MUTEX is set to 1.  It was set to 1 in 1.6.6
>  but to 0 in 1.6.15.
>
>  (This wouldn't explain why ASF saw it, but it might explain why you're
>  seeing it.)
>
>> Fail2ban from what I could find does not look like it has a Windows
>> port which I currently have my production environment hosted on.
>>
>
> Yeah, sorry.  But you can write a cron job -- I mean, a Scheduled Task
> -- that greps your error logs for "160004" every night and mails you it
> it found anything, right?
>
> That's the error code to watch for for many FS error conditions:
> % ./tools/dev/which-error.py E160004
> 00160004  SVN_ERR_FS_CORRUPT
>

I will look into it. We did ask developers to note any error messages
that they see from tortoisesvn now as the last time we saw the error
message pop up, we asked the developer what happened and he said that
an error message popped up and he just tried to check in again and it
worked. We will note the exact message next time.

>> Thanks.
>>
>> Jason
>
> For convenience I'm attaching a patch that implements both of my
> suggestions.  Let us know please if it has any effect.
>

I will forward this to the developer to look at.

> Cheers,
>
> Daniel
>

Hi.

See replies above. I will post what we find.

Thanks.

Jason

What's the process to svnsync a larger repository

[Geoff Hoffman]

I'm learning some gotchas with svnsync this week. As per my typical method
of learning I try 3 wrong ways before finally realizing the right way to do
most things.

We have about a 1GB svn repo on Ubuntu at -r 3738, and I'm trying to get it
mirrored on Win 7 running VisualSVN.

I created the mirror repository fine, ran svnsync init and svnsync sync on
it, then as it started going from -r 1, -r 2, -r 3..., I realized it would
take a week or more to fetch all nearly 4K commits.

So I stopped it, deleted it, started over and did an svnadmin dump -->
svnadmin load from the dump -- which ran/imported much faster, but now when
I try to initialize the sync, I get

svnsync: Cannot initialize a repository with content in it

D'OH! I forgot to svnsync init after creating the empty mirror repo. Whoops.

So, my question is, before I whack a perfectly fine "almost mirrored"
repository, can I svn propset -r 0 all the stuff needed by svnsync
manually, to start syncing at -r 3738?

Or can I set up the repo again (svnadmin create immediately followed by
svnsync init) and then svnadmin load (since load from a dump is so much
faster)?

It would seem odd that the only way to mirror a repo is to replay
everything from -r 0.

Thanks for your guidance!

Geoff

-- 


This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

Re: adding a new file to ignore does not enable the OK button in the commit dialog

[Ryan Schmidt]

On Mar 2, 2012, at 03:54, Mark van Tilburg wrote:

> When you add a new and then choose to ignore it, the folder gets
> selected but the ok button stays grayed out.

Sounds like you're describing an issue with TortoiseSVN; report it to the 
TortoiseSVN mailing list, not here.

Re: What's the process to svnsync a larger repository

[Mark Phippard]

On Fri, Mar 2, 2012 at 10:41 AM, Geoff Hoffman
 wrote:
> I'm learning some gotchas with svnsync this week. As per my typical method
> of learning I try 3 wrong ways before finally realizing the right way to do
> most things.
>
> We have about a 1GB svn repo on Ubuntu at -r 3738, and I'm trying to get it
> mirrored on Win 7 running VisualSVN.
>
> I created the mirror repository fine, ran svnsync init and svnsync sync on
> it, then as it started going from -r 1, -r 2, -r 3..., I realized it would
> take a week or more to fetch all nearly 4K commits.
>
> So I stopped it, deleted it, started over and did an svnadmin dump -->
> svnadmin load from the dump -- which ran/imported much faster, but now when
> I try to initialize the sync, I get
>
> svnsync: Cannot initialize a repository with content in it
>
> D'OH! I forgot to svnsync init after creating the empty mirror repo. Whoops.
>
> So, my question is, before I whack a perfectly fine "almost mirrored"
> repository, can I svn propset -r 0 all the stuff needed by svnsync manually,
> to start syncing at -r 3738?
>
> Or can I set up the repo again (svnadmin create immediately followed by
> svnsync init) and then svnadmin load (since load from a dump is so much
> faster)?
>
> It would seem odd that the only way to mirror a repo is to replay everything
> from -r 0.

This is, in fact, a limitation of svnsync.  You can manually setup the
properties on r0 as one option, or if you have svnsync from 1.7
installed, you can use the new --allow-non-empty option on the init
command and it essentially will do the same thing for you.

-- 
Thanks

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

Re: What's the process to svnsync a larger repository

[Geoff Hoffman]

Yeah I was just reading this:

"By default, the aforementioned basic requirements of a mirror are that it
> allows revision property modifications and that it contains no version
> history. However, as of Subversion 1.7, you may now optionally disable the
> verification that the target repository is empty using the
> --allow-non-empty option. While the use of this option should not become
> habitual (as it bypasses a valuable safeguard mechanism), it does aid in
> one very common use-case: initializing a copy of a repository as a mirror
> of the original. This is especially handy when setting up new mirrors of
> repositories which contain a large amount of version history. Rather than
> initialize a brand new repository as a mirror and then syncronize all of
> the history into it, administrators will find it *significantly* faster
> to first make a copy of the mature repository (perhaps using *svnadmin
> hotcopy*) and then use *svnsync initialize --allow-non-empty* to
> initialize that copy as a mirror which is now already up-to-date with the
> original."



Now here's the interesting part. I'm running svn 1.6 on the source repo,
1.7 on the mirror repo... (I think)



Geoff Hoffman
Solutions Architect & LAMP Engineer
_
Twitter: @m2guru  |
@cardinalpath
LinkedIn: www.linkedin.com/in/geoffreydhoffman
Phone: 480.285.1622 x313
Mobile: 480.231.8323
_
www.cardinalpath.com
training.cardinalpath.com

*PublicInsite, VKI Studios, and WebShare have merged to form Cardinal Path*




On Fri, Mar 2, 2012 at 8:45 AM, Mark Phippard  wrote:

> On Fri, Mar 2, 2012 at 10:41 AM, Geoff Hoffman
>  wrote:
> > I'm learning some gotchas with svnsync this week. As per my typical
> method
> > of learning I try 3 wrong ways before finally realizing the right way to
> do
> > most things.
> >
> > We have about a 1GB svn repo on Ubuntu at -r 3738, and I'm trying to get
> it
> > mirrored on Win 7 running VisualSVN.
> >
> > I created the mirror repository fine, ran svnsync init and svnsync sync
> on
> > it, then as it started going from -r 1, -r 2, -r 3..., I realized it
> would
> > take a week or more to fetch all nearly 4K commits.
> >
> > So I stopped it, deleted it, started over and did an svnadmin dump -->
> > svnadmin load from the dump -- which ran/imported much faster, but now
> when
> > I try to initialize the sync, I get
> >
> > svnsync: Cannot initialize a repository with content in it
> >
> > D'OH! I forgot to svnsync init after creating the empty mirror repo.
> Whoops.
> >
> > So, my question is, before I whack a perfectly fine "almost mirrored"
> > repository, can I svn propset -r 0 all the stuff needed by svnsync
> manually,
> > to start syncing at -r 3738?
> >
> > Or can I set up the repo again (svnadmin create immediately followed by
> > svnsync init) and then svnadmin load (since load from a dump is so much
> > faster)?
> >
> > It would seem odd that the only way to mirror a repo is to replay
> everything
> > from -r 0.
>
> This is, in fact, a limitation of svnsync.  You can manually setup the
> properties on r0 as one option, or if you have svnsync from 1.7
> installed, you can use the new --allow-non-empty option on the init
> command and it essentially will do the same thing for you.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>

-- 


This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

Re: What's the process to svnsync a larger repository

[Philip Martin]

Geoff Hoffman  writes:

> So, my question is, before I whack a perfectly fine "almost mirrored"
> repository, can I svn propset -r 0 all the stuff needed by svnsync
> manually, to start syncing at -r 3738?

Yes.  You need --revprop with the propset.

-- 
Philip

Re: Feature request: allow for relative working copy paths in svn:externals definition

[Les Mikesell]

On Fri, Mar 2, 2012 at 9:21 AM, Humm, Markus
 wrote:
>
> We created a Junction inside D:\Test\Projekt1 named
> D:\Test\Projekt1\JunctionTest which points to
> D:\Test\Common

Can you do this the other way around?  That is, make D:\Test\Common
the junction point, pointing to wherever your svn external is going to
drop the files?And figure out what it is you really want to happen
in the case where you want to check out D:\Test\Projek1 and
D:\Test\Projek2 and they both have the same relationship to
D:\Test\Common but want different revisions to appear there.

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

AW: Feature request: allow for relative working copy paths in svn:externals definition

[Humm, Markus]

Hello,
>>
>> We created a Junction inside D:\Test\Projekt1 named 
>> D:\Test\Projekt1\JunctionTest which points to D:\Test\Common
>
> Can you do this the other way around?  That is, make D:\Test\Common
the junction point, pointing to wherever your svn external is going to
> drop the files?And figure out what it is you really want to happen
> in the case where you want to check out D:\Test\Projek1 and
> D:\Test\Projek2 and they both have the same relationship to
D:\Test\Common but want different revisions to appear there.
 
No, the other way round doesn't work, because d:\Test\Common cannot
point at the same time both to
D:\Test\Projekt1\JunctionTest and D:\Test\Project2\JunctionTest. We just
tested this. The question now is, why does SVN detect our hardlinked 
directory as special type of directory and thus creates us pain? (as
otherwise we'd have a solution which could work for us)

Best regards

Markus Humm


ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart 
HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter 
Fuchs, Dr. Bruno Lindl, Thomas Wagner

Re: What's the process to svnsync a larger repository

[Geoff Hoffman]

Sweet - if that works it'll save a lot of time. Can someone paste an svn
proplist --revprop -r 0 from a mirror repo so I can see all the stuff to
set?


On Fri, Mar 2, 2012 at 8:47 AM, Philip Martin wrote:

> Geoff Hoffman  writes:
>
> > So, my question is, before I whack a perfectly fine "almost mirrored"
> > repository, can I svn propset -r 0 all the stuff needed by svnsync
> > manually, to start syncing at -r 3738?
>
> Yes.  You need --revprop with the propset.
>
> --
> Philip
>

-- 


This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

Re: What's the process to svnsync a larger repository

[Mark Phippard]

On Fri, Mar 2, 2012 at 10:47 AM, Geoff Hoffman wrote:

> Yeah I was just reading this:
>
> "By default, the aforementioned basic requirements of a mirror are that it
>> allows revision property modifications and that it contains no version
>> history. However, as of Subversion 1.7, you may now optionally disable the
>> verification that the target repository is empty using the
>> --allow-non-empty option. While the use of this option should not become
>> habitual (as it bypasses a valuable safeguard mechanism), it does aid in
>> one very common use-case: initializing a copy of a repository as a mirror
>> of the original. This is especially handy when setting up new mirrors of
>> repositories which contain a large amount of version history. Rather than
>> initialize a brand new repository as a mirror and then syncronize all of
>> the history into it, administrators will find it *significantly* faster
>> to first make a copy of the mature repository (perhaps using *svnadmin
>> hotcopy*) and then use *svnsync initialize --allow-non-empty* to
>> initialize that copy as a mirror which is now already up-to-date with the
>> original."
>
>
>
> Now here's the interesting part. I'm running svn 1.6 on the source repo,
> 1.7 on the mirror repo... (I think)
>
>
If the svnsync command you use is from 1.7.x it will work.  Does not matter
what version the server you are synching is running.

-- 
Thanks

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

Re: What's the process to svnsync a larger repository

[Geoff Hoffman]

On Fri, Mar 2, 2012 at 8:47 AM, Philip Martin wrote:

> Geoff Hoffman  writes:
>
> > So, my question is, before I whack a perfectly fine "almost mirrored"
> > repository, can I svn propset -r 0 all the stuff needed by svnsync
> > manually, to start syncing at -r 3738?
>
> Yes.  You need --revprop with the propset.
>
> --
> Philip
>



I'm going to try setting svn:sync-* props by hand first...

>From this post
http://journal.paul.querna.org/articles/2006/09/14/using-svnsync/
I guess I need to set four properties by hand...

$ svn proplist --revprop -r 0 ${TOREPO}

  svn:sync-from-uuid
  svn:sync-last-merged-rev
  svn:date
  svn:sync-from-url

I retrieved the uuid from the source repo like so

#> svn info http://localhost/svn/source-repo -r 3738
URL: http://localhost/svn/source-repo
Repository Root: http://localhost/svn/source-repo
Repository UUID: 9c96f4c0-7d9a-42f6-b8c8-54e79b961fad
Revision: 3738

Okay, the sync-from-url is easy, last-merged-rev is 3738... what format is
the svn:date in? Anyone know?

-- 


This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

Re: predecessor count for the root node-revision is wrong message

[Daniel Shahaf]

Jason Wong wrote on Fri, Mar 02, 2012 at 07:32:38 -0800:
> On Fri, Mar 2, 2012 at 2:58 AM, Daniel Shahaf  wrote:
> > Jason Wong wrote on Thu, Mar 01, 2012 at 10:01:26 -0800:
> >> I have had a developer here create a build of the latest SVN code
> >> with your changes you mentioned in r1294470 for the svnadmin verify
> >
> > Okay, that's great news, for two reasons:
> >
> > 1. It means building svn on windows isn't as painful as it used to be :)
> 
> Actually, it did take some work to get it going as we did not have
> another system available to us and also did not have VC++ 6. We had
> to use VS 2010 in order to do this. Also, for the other components
> required (python,perl etc), the files after the install were copied
> to the workstation to see if it would work as we did not want to
> change the current workstation configuration by running the
> installers. All in all, it did seem to work.
> 

Okay.  The normal build requires just the *.exe and *.dll files to be
placed appropriately (such that the *.exe's and httpd's find their
libsvn_* DLL's at runtime) --- it doesn't require Administrator access,
for example.

To clarify, Perl is only required to build OpenSSL; it is not required
to build APR, Neon, or Subversion.

> >
> > 2. It means I can ask you to build a custom server with the 'inprocess'
> > cache disabled, or (if all else fails) to bisect, per my previous email.
> >
> > One of the things you could try is to disable caching: simply modify
> > the function create_cache() in libsvn_fs_fs/caching.c to always return
> > NULL in *CACHE_P.  See below for another suggestion.
> >
> >> command. We have run 'svnadmin verify' against every revision of our
> >> hotcopy of our repository taken when we first brought this issue to
> >> the forums and are now tracking down each of the revisions to see
> >> what actions were being done at those times.
> >>
> >
> > Thanks!  I do hope this work enables us to pinpoint and fix the bug.
> 
> I will be going through the list to see what else was happening at the
> same time on the apache server since it was alluded to that there may
> be concurrency issues. I know the last two times that this error has
> popped up, we had two svn operations starting at around the same time
> according to the Apache logs. I will go through the previous apache
> history to see if this was always the case or not.
> 

Thanks, looking forward to hear what you come up with.

FWIW, Justin's reply suggests that the error was seen on three different
platforms --- Windows, Solaris, and FreeBSD --- so that should narrow
down the range of possible explanations.

(I'll also note that at ASF's installation we are not running into new
instances of the bug.)

Re: What's the process to svnsync a larger repository

[Les Mikesell]

On Fri, Mar 2, 2012 at 9:41 AM, Geoff Hoffman  wrote:
> I'm learning some gotchas with svnsync this week. As per my typical method
> of learning I try 3 wrong ways before finally realizing the right way to do
> most things.
>
> We have about a 1GB svn repo on Ubuntu at -r 3738, and I'm trying to get it
> mirrored on Win 7 running VisualSVN.
>
> I created the mirror repository fine, ran svnsync init and svnsync sync on
> it, then as it started going from -r 1, -r 2, -r 3..., I realized it would
> take a week or more to fetch all nearly 4K commits.

Slow is one thing - but that sounds unreasonable.  Is there some
network issue involved?  Maybe you can svnsync on a nearby machine,
then copy or move the resulting repo once it is caught up.

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

Re: Feature request: allow for relative working copy paths in svn:externals definition

[Les Mikesell]

On Fri, Mar 2, 2012 at 9:58 AM, Humm, Markus
 wrote:
>
>>> We created a Junction inside D:\Test\Projekt1 named
>>> D:\Test\Projekt1\JunctionTest which points to D:\Test\Common
>>
>> Can you do this the other way around?  That is, make D:\Test\Common
> the junction point, pointing to wherever your svn external is going to
>> drop the files?    And figure out what it is you really want to happen
>> in the case where you want to check out D:\Test\Projek1 and
>> D:\Test\Projek2 and they both have the same relationship to
> D:\Test\Common but want different revisions to appear there.
>
> No, the other way round doesn't work, because d:\Test\Common cannot
> point at the same time both to
> D:\Test\Projekt1\JunctionTest and D:\Test\Project2\JunctionTest. We just
> tested this. The question now is, why does SVN detect our hardlinked
> directory as special type of directory and thus creates us pain? (as
> otherwise we'd have a solution which could work for us)

I think you are going to have a very, very confusing time if you do
get the common directory to simultaneously be junctioned (either
direction) to externals that can be pointed at different revisions.
What is it you would like to happen in that case?

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

Re: What's the process to svnsync a larger repository

[Geoff Hoffman]

On Fri, Mar 2, 2012 at 9:13 AM, Les Mikesell  wrote:

> On Fri, Mar 2, 2012 at 9:41 AM, Geoff Hoffman 
> wrote:
> > I'm learning some gotchas with svnsync this week. As per my typical
> method
> > of learning I try 3 wrong ways before finally realizing the right way to
> do
> > most things.
> >
> > We have about a 1GB svn repo on Ubuntu at -r 3738, and I'm trying to get
> it
> > mirrored on Win 7 running VisualSVN.
> >
> > I created the mirror repository fine, ran svnsync init and svnsync sync
> on
> > it, then as it started going from -r 1, -r 2, -r 3..., I realized it
> would
> > take a week or more to fetch all nearly 4K commits.
>
> Slow is one thing - but that sounds unreasonable.  Is there some
> network issue involved?  Maybe you can svnsync on a nearby machine,
> then copy or move the resulting repo once it is caught up.
>
> --
>   Les Mikesell
>lesmikes...@gmail.com
>


The speed issue is that I'm storing the mirror repo on a slow computer, on
a USB Drobo that is in turn being backed up to an online backup service.


Good news- Thanks guys, looks like I got it syncing forward from -r 3738!

Here's cmd output from Windows box -- hopefully it helps someone in the
future.


X:\Repositories>svn propset --revprop -r0 svn:sync-last-merged-rev 3738
http://mirror-server/svn/mirror-repo
property 'svn:sync-last-merged-rev' set on repository revision 0

X:\Repositories>svnsync sync http://mirror-server/svn/mirror-repo
svnsync: Destination repository has not been initialized

X:\Repositories>svn propset --revprop -r0 svn:sync-from-uuid
9c96f4c0-7d9a-42f6-
b8c8-54e79b961fad http://mirror-server/svn/mirror-repo
property 'svn:sync-from-uuid' set on repository revision 0

X:\Repositories>svn propset --revprop -r0 svn:sync-from-url
http://source-server/svn/source-repo http://mirror-server/svn/mirror-repo
property 'svn:sync-from-url' set on repository revision 0

X:\Repositories>svnsync sync http://mirrorr-server/svn/mirror-repo
Transmitting file data .
Committed revision 3739.
Copied properties for revision 3739.

-- 


This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

Re: What's the process to svnsync a larger repository

[Les Mikesell]

On Fri, Mar 2, 2012 at 10:20 AM, Geoff Hoffman
 wrote:
>
>> > I created the mirror repository fine, ran svnsync init and svnsync sync
>> > on
>> > it, then as it started going from -r 1, -r 2, -r 3..., I realized it
>> > would
>> > take a week or more to fetch all nearly 4K commits.
>>
>> Slow is one thing - but that sounds unreasonable.  Is there some
>> network issue involved?  Maybe you can svnsync on a nearby machine,
>> then copy or move the resulting repo once it is caught up.
>>

> The speed issue is that I'm storing the mirror repo on a slow computer, on a
> USB Drobo that is in turn being backed up to an online backup service.

But you should be able to copy a whole repo, maintaining state as long
as the target is reasonably similar.  I see you have gotten it to work
another way, but you should have been able to do the initial catch-up
sync on something faster, copy that repository where you want it, then
resume the syncs to keep it updated.

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

AW: Feature request: allow for relative working copy paths in svn:externals definition

[Humm, Markus]

Hello,

>>
 We created a Junction inside D:\Test\Projekt1 named 
 D:\Test\Projekt1\JunctionTest which points to D:\Test\Common
>>>
>>> Can you do this the other way around?  That is, make D:\Test\Common
>> the junction point, pointing to wherever your svn external is going to
>>> drop the files?    And figure out what it is you really want to 
>>> happen in the case where you want to check out D:\Test\Projek1 and
>>> D:\Test\Projek2 and they both have the same relationship to
>> D:\Test\Common but want different revisions to appear there.
>>
>> No, the other way round doesn't work, because d:\Test\Common cannot 
>> point at the same time both to D:\Test\Projekt1\JunctionTest and 
>> D:\Test\Project2\JunctionTest. We just tested this. The question now 
>> is, why does SVN detect our hardlinked directory as special type of 
>> directory and thus creates us pain? (as otherwise we'd have a solution 
>> which could work for us)
>
> I think you are going to have a very, very confusing time if you do get the 
> common directory to simultaneously be junctioned (either
> direction) to externals that can be pointed at different revisions.
> What is it you would like to happen in that case?

That is not a real problem for me, as I only work at Project1 XOR Project2 at 
any given time.
When I switch to the other project I have to update it first which would 
replace the common files.

Best regards

Markus Humm


ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart 
HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter 
Fuchs, Dr. Bruno Lindl, Thomas Wagner

Re: What's the process to svnsync a larger repository

[Geoff Hoffman]

On Fri, Mar 2, 2012 at 9:25 AM, Les Mikesell  wrote:

> On Fri, Mar 2, 2012 at 10:20 AM, Geoff Hoffman
>  wrote:
> >
> >> > I created the mirror repository fine, ran svnsync init and svnsync
> sync
> >> > on
> >> > it, then as it started going from -r 1, -r 2, -r 3..., I realized it
> >> > would
> >> > take a week or more to fetch all nearly 4K commits.
> >>
> >> Slow is one thing - but that sounds unreasonable.  Is there some
> >> network issue involved?  Maybe you can svnsync on a nearby machine,
> >> then copy or move the resulting repo once it is caught up.
> >>
>
> > The speed issue is that I'm storing the mirror repo on a slow computer,
> on a
> > USB Drobo that is in turn being backed up to an online backup service.
>
> But you should be able to copy a whole repo, maintaining state as long
> as the target is reasonably similar.  I see you have gotten it to work
> another way, but you should have been able to do the initial catch-up
> sync on something faster, copy that repository where you want it, then
> resume the syncs to keep it updated.



This is pretty much exactly what I did, Les.

My other question from my initial post is, should I be doing it in exactly
this order:

// source-server
1. svnadmin dump source-repo > source.dump
2. tgz it and scp it to mirror-server
// mirror-server
3. svnadmin create mirror-repo
4. svnsync init here !! * // this is what I didn't do before*
5. svnadmin load ? or do you have to just let it sync from -r 0

With 1.6x and before, it may be just as easy to issue 3 propsets as above.
I think I'll write a blog post on this. There doesn't seem to be a single
concise procedure outlined anywhere on the net. Although, it's nice to
learn that svn 1.7+ added the --allow-non-empty option.

-- 


This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

Re: What's the process to svnsync a larger repository

[Les Mikesell]

On Fri, Mar 2, 2012 at 10:33 AM, Geoff Hoffman
 wrote:
>
>> But you should be able to copy a whole repo, maintaining state as long
>> as the target is reasonably similar.  I see you have gotten it to work
>> another way, but you should have been able to do the initial catch-up
>> sync on something faster, copy that repository where you want it, then
>> resume the syncs to keep it updated.
>
>
> This is pretty much exactly what I did, Les.

I meant, create your mirror initially with svnsync from scratch on a
fast local system instead of using the dump/load.  Then copy the whole
mirror repo to the system/drive where you wanted it, and svnsync
should pick up where it left off assuming the network reference still
works from the new location.

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

Re: Subversion multi-Project Repository: how to?

[Pietro Moras]

>
 Subversion doesn't define the term "project". 

  And
that's it! Thank you, Uli.


  You
see [see also my former post: “Subversion
Repository: naturally a single- or multi-Project versioning
storage?”], I'm currently engaged with a project of Test &
Documentation of the “versioning” feature (i.e. Subversion)
integrated into the Eric (4) Python IDE, and I'm facing the fact
that, while Eric has a very well defined Project concept, Subversion,
clearly, hasn't. 

As
simple as that.
Thank
you again for you clarifying and convincing consideration.
All
the best. Yours, -
P.M.

  

Re: svn diff on png files

[Stefan Sperling]

On Fri, Mar 02, 2012 at 09:47:12AM +, Philip Martin wrote:
> SravanKumar Sandela  writes:
> 
> > 5. If this is buggy, has it been already fixed, if not then what does the
> >
> >
> > ## -0,0 +1 ##
> > +image/png
> >
> >   mean?
> 
> It's intentional, 1.7 shows property diffs as unified diffs:
> 
> http://subversion.apache.org/docs/release-notes/1.7.html#diff-properties

Also, mime-type detection with libmagic switches the automatically
configured mime-type from 'application/octet-stream' to 'image/png'.
http://subversion.apache.org/docs/release-notes/1.7.html#libmagic-support
If you don't like this, either compile Subversion without libmagic,
or make the MAGIC environment variable in svn's environment point to
a file that does not exist or is empty.

There is no way to get the 1.6 property diff output back with a 1.7
client. I'm sorry that this incompatible change breaks your script.
The reason this change was made is that 'svn patch' needs to parse
property changes from patch files and apply them to a working copy.

Re: Best approach to break up a repository

[Mattius McLaughlin]

On 03/01/12 19:40, Ryan Schmidt wrote:

On Mar 1, 2012, at 15:46, Mattius McLaughlin wrote:


I'd like to break each of those projects into separate repositories.  Given the 
number of designers we have, it's a bit unreasonable to expect everyone to 
recreate every workspace so I'd like to keep all URLs the same.

There's no choice; when you split the big repository into smaller repositories, 
each repository must be given its own UUID (Universally Unique IDentifier), 
different from the big repository's UUID. A working copy is matched to a 
particular repository by UUID. Once you have new repositories, you must check 
out new working copies. No exceptions.


I know it's not necessarily best practice, but one could get around this 
with a svnadmin setuuid $old-uuid, no?

Re: Best approach to break up a repository

[Les Mikesell]

On Thu, Mar 1, 2012 at 9:40 PM, Ryan Schmidt
 wrote:

>> I'd like to break each of those projects into separate repositories.  Given 
>> the number of designers we have, it's a bit unreasonable to expect everyone 
>> to recreate every workspace so I'd like to keep all URLs the same.
>
> There's no choice; when you split the big repository into smaller 
> repositories, each repository must be given its own UUID (Universally Unique 
> IDentifier), different from the big repository's UUID. A working copy is 
> matched to a particular repository by UUID. Once you have new repositories, 
> you must check out new working copies. No exceptions.
>

You could pick one of the projects to keep in the existing repository
and simply delete the other one in the HEAD view.  Then only the
workspaces for the other project would have be checked out again.  But
I didn't understand the comments about replicating/moving etc.  What
is the real issue here?  Are there groups that work on one of the
projects without good network access?

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

Merging a vendor branch that's also in subversion

[Steve Lustbader]

My subversion-based project is based on a third-party project that is also
stored in subversion, although on a separate server (to which we only have
client access). We will soon need to merge the recent changes from the
third-party project back into our own codebase. I am preparing to do a
merge using the "vendor branch" technique from the svn book, but I was
hoping that since both projects are stored in subversion, there might be a
simpler way - are there any other options?

Thanks,
Steve

Re: Merging a vendor branch that's also in subversion

[Stefan Sperling]

On Fri, Mar 02, 2012 at 02:01:58PM -0500, Steve Lustbader wrote:
> My subversion-based project is based on a third-party project that is also
> stored in subversion, although on a separate server (to which we only have
> client access). We will soon need to merge the recent changes from the
> third-party project back into our own codebase. I am preparing to do a
> merge using the "vendor branch" technique from the svn book, but I was
> hoping that since both projects are stored in subversion, there might be a
> simpler way - are there any other options?

Another option might be a foreign repository merge.
Quoting from near the bottom of 'svn help merge' output:

- Merging from foreign repositories -

  Subversion does support merging from foreign repositories.
  While all merge source URLs must point to the same repository, the merge
  target working copy may come from a different repository than the source.
  However, there are some caveats. Most notably, copies made in the
  merge source will be transformed into plain additions in the merge
  target. Also, merge-tracking is not supported for merges from foreign
  repositories.

Re: Merging a vendor branch that's also in subversion

[Steve Lustbader]

On Fri, Mar 2, 2012 at 2:25 PM, Stefan Sperling  wrote:

> On Fri, Mar 02, 2012 at 02:01:58PM -0500, Steve Lustbader wrote:
> > My subversion-based project is based on a third-party project that is
> also
> > stored in subversion, although on a separate server (to which we only
> have
> > client access). We will soon need to merge the recent changes from the
> > third-party project back into our own codebase. I am preparing to do a
> > merge using the "vendor branch" technique from the svn book, but I was
> > hoping that since both projects are stored in subversion, there might be
> a
> > simpler way - are there any other options?
>
> Another option might be a foreign repository merge.
> Quoting from near the bottom of 'svn help merge' output:
>
>- Merging from foreign repositories -
>
>  Subversion does support merging from foreign repositories.
>  While all merge source URLs must point to the same repository, the merge
>  target working copy may come from a different repository than the source.
>  However, there are some caveats. Most notably, copies made in the
>  merge source will be transformed into plain additions in the merge
>  target. Also, merge-tracking is not supported for merges from foreign
>  repositories.
>

Thanks, that looks like exactly what I wanted, so I'll give it a shot.

-Steve

Re: details for product

[Chris Albertson]

On Thu, Mar 1, 2012 at 11:59 PM,   wrote:
> Hello,
>
> We are looking for versioning software.
>
> Request you to please provide following information about this product.
> 1. What is licensing policy.(like whether it is licensed, if yes what is the
> cost for server and client installation)
> 2. how it manages centralized repository for code.
> 3. does it have any demo version.

#1, #2, You can down load a FREE book on subversion.   All the answers
are in it. (You can also buy a printed copy if you like)
http://svnbook.red-bean.com/

#3 It does not make sense to have a "demo" for free software.   Simply
download and use the actual product.


Chris Albertson
Redondo Beach, California

Re: Best approach to break up a repository

[Ryan Schmidt]

On Mar 2, 2012, at 12:54, Mattius McLaughlin wrote:

> 
> 
> On 03/01/12 19:40, Ryan Schmidt wrote:
>> On Mar 1, 2012, at 15:46, Mattius McLaughlin wrote:
>> 
>>> I'd like to break each of those projects into separate repositories.  Given 
>>> the number of designers we have, it's a bit unreasonable to expect everyone 
>>> to recreate every workspace so I'd like to keep all URLs the same.
>> There's no choice; when you split the big repository into smaller 
>> repositories, each repository must be given its own UUID (Universally Unique 
>> IDentifier), different from the big repository's UUID. A working copy is 
>> matched to a particular repository by UUID. Once you have new repositories, 
>> you must check out new working copies. No exceptions.
>> 
>> 
> I know it's not necessarily best practice, but one could get around this with 
> a svnadmin setuuid $old-uuid, no?

Unless the new repository's history is identical to the old repository, it must 
not have the same UUID; doing so would confuse clients and existing working 
copies.

Re: svn diff on png files

[SravanKumar Sandela]

Hi Philip, Stefan,

Thanks for the info, the svn we are using is from cygwin tool, and we did
not compile any svn exclusively, it has just been a download and install
process. Can you point me more to MAGIC environment variable setting to an
empty file?, like how to do it?.

This is important for us, because users around the world have not yet
completely shifted to 1.7, but once they shift or for new comers, we have
to fix the script to take care of this issue, so can u please tell us how
and where to find this MAGIC env var and how could it be set?.

Thanks in anticipation.

-Sravan.

On Sat, Mar 3, 2012 at 12:05 AM, Stefan Sperling  wrote:

> On Fri, Mar 02, 2012 at 09:47:12AM +, Philip Martin wrote:
> > SravanKumar Sandela  writes:
> >
> > > 5. If this is buggy, has it been already fixed, if not then what does
> the
> > >
> > >
> > > ## -0,0 +1 ##
> > > +image/png
> > >
> > >   mean?
> >
> > It's intentional, 1.7 shows property diffs as unified diffs:
> >
> > http://subversion.apache.org/docs/release-notes/1.7.html#diff-properties
>
> Also, mime-type detection with libmagic switches the automatically
> configured mime-type from 'application/octet-stream' to 'image/png'.
> http://subversion.apache.org/docs/release-notes/1.7.html#libmagic-support
> If you don't like this, either compile Subversion without libmagic,
> or make the MAGIC environment variable in svn's environment point to
> a file that does not exist or is empty.
>
> There is no way to get the 1.6 property diff output back with a 1.7
> client. I'm sorry that this incompatible change breaks your script.
> The reason this change was made is that 'svn patch' needs to parse
> property changes from patch files and apply them to a working copy.
>

Re: svn diff on png files

[Ryan Schmidt]

On Mar 2, 2012, at 21:40, SravanKumar Sandela wrote:

> This is important for us, because users around the world have not yet 
> completely shifted to 1.7, but once they shift or for new comers, we have to 
> fix the script to take care of this issue

You should modify your script now so that it can adapt and behave correctly 
depending on whether Subversion < 1.7 or >= 1.7 is used.

Re: svn diff on png files

[SravanKumar Sandela]

Yes exactly, and i want to update MAGIC env variable from script. But to do
that i need to understand how and what to set it to.

On Sat, Mar 3, 2012 at 10:38 AM, Ryan Schmidt <
subversion-20...@ryandesign.com> wrote:

> On Mar 2, 2012, at 21:40, SravanKumar Sandela wrote:
>
> > This is important for us, because users around the world have not yet
> completely shifted to 1.7, but once they shift or for new comers, we have
> to fix the script to take care of this issue
>
> You should modify your script now so that it can adapt and behave
> correctly depending on whether Subversion < 1.7 or >= 1.7 is used.
>
>