Advice on how to merge bug fix from branch to trunk

[Jean Seurin]

Hi,

we have a problem we can't solve yet with Subversion.
In our process, we create a branch of a version that is going to be 
released. Then we release from that branch and create a tag for each 
released version.


The problem lies in the bug fix of this released version. We have to 
apply manually the fix to the branch, release a new tag, and then report 
the same modification to the trunk.


Developer are really loath to do that. They have enough pression to fix 
the bug quickly, not to take some more to keep the process consistant.


I have to find a way to facilitate this bug porting from branch to trunk.

Unfortunately I can't find any merge example made with this 
configuration. It seems it's designed to work the other way, trunk -> 
branch.


I'd be interested in others people use of SVN to support their release 
process.

Is there a way to get that bug porting made easy with some merge command?

best rgds,
Jean

Re: Advice on how to merge bug fix from branch to trunk

[Ulrich Eckhardt]

On Monday 11 January 2010, Jean Seurin wrote:
> I have to find a way to facilitate this bug porting from branch to trunk.
>
> Unfortunately I can't find any merge example made with this
> configuration. It seems it's designed to work the other way, trunk ->
> branch.

Subversion doesn't care about the difference between branches and trunk, those 
are just conventions. In other words, you can simply merge in both directions 
without problems.

Uli

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

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

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

RE: Copy data from one repos to another and history should not be losed

[Ullrich.Jans]

Ryan Schmidt wrote:
> On Jan 5, 2010, at 06:02, Chetan Chatwani wrote:
> 
>> We have two repositories names as  : bmrepos and bmdevrepos.
>> We want to copy/add data from bmrepos to bmdevrepos but history
>> should not losed. 
>> 
>> Note: bpmrepos already have some contents.
> 
> Yes, you can do this with "svnadmin dump" and "svnadmin load".

But watch out: the dates in the revisions will not be linear afterwards, so 
searching for revisions by date will not work any more. (AFAIK)

Cheers,

Ulli

-- 
Ullrich Jans, Application Support, IM
Phone: +49 9131 7701-6627, mailto:ullrich.j...@elektrobit.com 
Fax: +49 9131 7701-6333, www.elektrobit.com

Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany
Managing Directors: Otto Fößel, Jarkko Sairanen
Register Court Fürth HRB 4886 



Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

More strict file permissions for the administrative ".svn" directories

[Ivan Zahariev]

Hello guys,

Many developers checkout the working tree directly into the web server's
public folder, and this imposes a security risk. Anyone can then point
the URL of their browser within the ".svn/text-base" directory, for
example, and access sensitive data such as previous versions of a file,
or even the source code of it, because of the ".svn-base" suffix in the
filename. This is described in more details at
"http://scottbarnham.com/blog/2008/04/22/serving-websites-from-svn-checkout-considered-harmful/";.
I know that "svn export" exists and this is the way to checkout the tree
properly and safely, but this is an extra step which developers have to
do, and you know that extra steps are usually skipped, if they could be
skipped.

Nevertheless, I see no valid reason for the administrative ".svn"
directories to be world-wide accessible; correct me if I'm wrong. That's
why I propose that SVN creates these ".svn" directories with file
permissions which disallow "others" to enter these directories. Here is
the proposed patch against the source code of Subversion 1.6.6:

--- ./subversion/libsvn_wc/adm_files.c-orig 2010-01-11
12:47:23.0 +0200
+++ ./subversion/libsvn_wc/adm_files.c  2010-01-11 12:48:57.0 +0200
@@ -627,7 +627,8 @@
 make_empty_adm(const char *path, apr_pool_t *pool)
 {
   path = svn_wc__adm_child(path, NULL, pool);
-  return svn_io_dir_make_hidden(path, APR_OS_DEFAULT, pool);
+  /* Protect the administrative subdir from being accessible by
"others". */
+  return svn_io_dir_make_hidden(path, (APR_OS_DEFAULT & ~(APR_WEXECUTE
| APR_WWRITE | APR_WREAD)), pool);
 }

Please let me know what you think. Should I direct this to the "dev"
mailing list? Thanks.

Best regards,
Ivan Zahariev

Re: More strict file permissions for the administrative ".svn" directories

[Andy Levy]

On Mon, Jan 11, 2010 at 06:05, Ivan Zahariev  wrote:
> Hello guys,
>
> Many developers checkout the working tree directly into the web server's
> public folder, and this imposes a security risk. Anyone can then point
> the URL of their browser within the ".svn/text-base" directory, for
> example, and access sensitive data such as previous versions of a file,
> or even the source code of it, because of the ".svn-base" suffix in the
> filename. This is described in more details at
> "http://scottbarnham.com/blog/2008/04/22/serving-websites-from-svn-checkout-considered-harmful/";.
> I know that "svn export" exists and this is the way to checkout the tree
> properly and safely, but this is an extra step which developers have to
> do, and you know that extra steps are usually skipped, if they could be
> skipped.
>
> Nevertheless, I see no valid reason for the administrative ".svn"
> directories to be world-wide accessible; correct me if I'm wrong. That's
> why I propose that SVN creates these ".svn" directories with file
> permissions which disallow "others" to enter these directories. Here is
> the proposed patch against the source code of Subversion 1.6.6:

Why not just configure your webserver to return a 404 error on
requests for directories named .svn?
http://www.google.com/search?q=svn+directory+404

Re: More strict file permissions for the administrative ".svn" directories

[Samuel ROZE]

Hello,

I use "svn co" like I explain, so I can use "svn update" to simply
update my projects. I think that it can be a good idea to remove read
for "o" but an experimented sys admin should know that .svn directory
mustn't be accessible from the web !

I use Apache and there is my configuration line which send a 404 error
when a HTTP client ask for .svn directory:

RedirectMatch 404 /\\.svn(/|$)

So simple...
Regards,
Samuel ROZE.

Le lundi 11 janvier 2010 à 13:05 +0200, Ivan Zahariev a écrit :
> Hello guys,
> 
> Many developers checkout the working tree directly into the web server's
> public folder, and this imposes a security risk. Anyone can then point
> the URL of their browser within the ".svn/text-base" directory, for
> example, and access sensitive data such as previous versions of a file,
> or even the source code of it, because of the ".svn-base" suffix in the
> filename. This is described in more details at
> "http://scottbarnham.com/blog/2008/04/22/serving-websites-from-svn-checkout-considered-harmful/";.
> I know that "svn export" exists and this is the way to checkout the tree
> properly and safely, but this is an extra step which developers have to
> do, and you know that extra steps are usually skipped, if they could be
> skipped.
> 
> Nevertheless, I see no valid reason for the administrative ".svn"
> directories to be world-wide accessible; correct me if I'm wrong. That's
> why I propose that SVN creates these ".svn" directories with file
> permissions which disallow "others" to enter these directories. Here is
> the proposed patch against the source code of Subversion 1.6.6:
> 
> --- ./subversion/libsvn_wc/adm_files.c-orig 2010-01-11
> 12:47:23.0 +0200
> +++ ./subversion/libsvn_wc/adm_files.c  2010-01-11 12:48:57.0 +0200
> @@ -627,7 +627,8 @@
>  make_empty_adm(const char *path, apr_pool_t *pool)
>  {
>path = svn_wc__adm_child(path, NULL, pool);
> -  return svn_io_dir_make_hidden(path, APR_OS_DEFAULT, pool);
> +  /* Protect the administrative subdir from being accessible by
> "others". */
> +  return svn_io_dir_make_hidden(path, (APR_OS_DEFAULT & ~(APR_WEXECUTE
> | APR_WWRITE | APR_WREAD)), pool);
>  }
> 
> Please let me know what you think. Should I direct this to the "dev"
> mailing list? Thanks.
> 
> Best regards,
> Ivan Zahariev

Re: Question about excessive mergeinfo

[Stein Somers]

No explanation here, and not the same symptoms, but you're not the only 
one struggling with it. I have a pre-commit hook to detect mergeinfo 
below root, and remove it whenever it occurs, which is rare. The 
repository has only mergeinfo on root directories, merges are done only 
on roots, no switched or shallow WC. No externals either. Still, svn 
1.6.6 tries to push excessive mergeinfo your way. Luckily only plain and 
simple recursive mergeinfo.


When copying by URL a subdirectory from another branch to somewhere in a 
WC, the new subdirectory always gets a mergeinfo property. Its value is 
a copy of the mergeinfo of the root of the source branch (where this 
"root" is an interpretation of course; more accurately, it is the 
nearest (and only) higher directory that has a mergeinfo property, 
relative to the copied subdirectory). Not surprisingly, the new 
mergeinfo is a subset of the mergeinfo of the current working copy root: 
fewer branches listed, fewer revisions listed. In my interpretation of 
the rules, this mergeinfo is entirely useless. So no thank you, I don't 
commit it.


--
Stein

Re: More strict file permissions for the administrative ".svn" directories

[Ivan Zahariev]

Let's not turn this into an Apache discussion :)

The Apache config is pretty clear. I use it myself too. But what if
someone makes a symlink "evil -> ../../../user2/.svn" ? This cannot be
catched by the URL rewrite filter because the URL would look like
"http://example.tld/evil/text-base/db-config.php.svn-base";. Even if
"db-config.php" itself is not readable directly by the web server, the
".svn" copy might be and this is a security risk which you cannot
completely circumvent by URL rewrite rules. (P.S. I know there is
"SymlinksIfOwnerMatch") (P.P.S. URL rewrite rules have a slight
performance impact and are not always inherited the way we expect).

That's why I proposed to use the standard file permission bits. They
cannot be fooled by symlinks, wrong web server configs or anything
similar. Only by operator's mistakes but nothing can save you from this.

Back to my original question - shouldn't ".svn" administrative
directories be inaccessible by "others"? Just like OpenSSH requires that
its per-user config directory ~/.ssh is writable only by its owner and
nobody else.

Cheers.
--Ivan

Andy Levy wrote:
> On Mon, Jan 11, 2010 at 06:05, Ivan Zahariev  wrote:
>   
>> Hello guys,
>>
>> Many developers checkout the working tree directly into the web server's
>> public folder, and this imposes a security risk. Anyone can then point
>> the URL of their browser within the ".svn/text-base" directory, for
>> example, and access sensitive data such as previous versions of a file,
>> or even the source code of it, because of the ".svn-base" suffix in the
>> filename. This is described in more details at
>> "http://scottbarnham.com/blog/2008/04/22/serving-websites-from-svn-checkout-considered-harmful/";.
>> I know that "svn export" exists and this is the way to checkout the tree
>> properly and safely, but this is an extra step which developers have to
>> do, and you know that extra steps are usually skipped, if they could be
>> skipped.
>>
>> Nevertheless, I see no valid reason for the administrative ".svn"
>> directories to be world-wide accessible; correct me if I'm wrong. That's
>> why I propose that SVN creates these ".svn" directories with file
>> permissions which disallow "others" to enter these directories. Here is
>> the proposed patch against the source code of Subversion 1.6.6:
>> 
>
> Why not just configure your webserver to return a 404 error on
> requests for directories named .svn?
> http://www.google.com/search?q=svn+directory+404
>   

Re: Question about excessive mergeinfo

[Ulrich Eckhardt]

On Monday 11 January 2010, Stein Somers wrote:
> No explanation here, and not the same symptoms, but you're not the only
> one struggling with it. I have a pre-commit hook to detect mergeinfo
> below root, and remove it whenever it occurs, which is rare.

Doh. Wish I had had that idea earlier.

> When copying by URL a subdirectory from another branch to somewhere in a
> WC, the new subdirectory always gets a mergeinfo property. Its value is
> a copy of the mergeinfo of the root of the source branch (where this
> "root" is an interpretation of course; more accurately, it is the
> nearest (and only) higher directory that has a mergeinfo property,
> relative to the copied subdirectory).

Technically, a missing mergeinfo implicitly means that a dir or file has its 
parent dir's mergeinfo. This is even documented. So, the source dir doesn't 
actually get a new and different mergeinfo, it is only set on the dir 
explicitly now while it was implicit before.

> Not surprisingly, the new mergeinfo is a subset of the mergeinfo of the
> current working copy root: fewer branches listed, fewer revisions listed.
> In my interpretation of the rules, this mergeinfo is entirely useless.
> So no thank you, I don't commit it.

I think SVN wants you to not copy the file/dir but instead to merge the 
revision where it was added to the branch. Yes, a simple copy is easier to 
explain in some cases, though it doesn't capture all possible changes in a 
branch.

Cheers!

Uli

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

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

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

Re: Advice on how to merge bug fix from branch to trunk

[Tyler Roscoe]

On Mon, Jan 11, 2010 at 05:50:53PM +0800, Jean Seurin wrote:
> In our process, we create a branch of a version that is going to be 
> released. Then we release from that branch and create a tag for each 
> released version.

I assume you create the branch from the trunk?

> The problem lies in the bug fix of this released version. We have to 
> apply manually the fix to the branch, release a new tag, and then report 
> the same modification to the trunk.

The usual way to do this is to make the bugfix on trunk and then
cherrypick merge the change from trunk up to your branch. Is there a
reason you can't do it this way?

tyler

RE: Advice on how to merge bug fix from branch to trunk

[Bob Archer]

> On Mon, Jan 11, 2010 at 05:50:53PM +0800, Jean Seurin wrote:
> > In our process, we create a branch of a version that is going to
> be
> > released. Then we release from that branch and create a tag for
> each
> > released version.
> 
> I assume you create the branch from the trunk?
> 
> > The problem lies in the bug fix of this released version. We have
> to
> > apply manually the fix to the branch, release a new tag, and then
> report
> > the same modification to the trunk.
> 
> The usual way to do this is to make the bugfix on trunk and then
> cherrypick merge the change from trunk up to your branch. Is there
> a
> reason you can't do it this way?
> 

Why not make the fix on the branch then merge that to trunk? It works just as 
well. This is usually the work flow we use.

BOb

Setting auto properties after file(s) have been committed.

[Jeremy Conlin]

I just created some auto properties settings for my repository.  I
need to now apply these settings to all the files in my repository.
Is there some automated way to do this or do I have to do it manually?

Thanks,
Jeremy

Adding auto properties after file has been committed

[Jeremy]

I have a repository and just enabled/added some auto properties.  How
can I go back and add these properties to files already committed?  I
really don't want to do this manually and was hoping there was an
automated method to do this.

Thanks,
Jeremy

Re: Setting auto properties after file(s) have been committed.

[Andy Levy]

On Mon, Jan 11, 2010 at 12:43, Jeremy Conlin  wrote:
> I just created some auto properties settings for my repository.  I
> need to now apply these settings to all the files in my repository.
> Is there some automated way to do this or do I have to do it manually?

Check out svn_apply_autoprops.py [1]. You'll need to check out any of
the items which need the properties applied. Any existing properties
will be removed/overwritten.

1: 
http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn_apply_autoprops.py

Re: Setting auto properties after file(s) have been committed.

[Tyler Roscoe]

On Mon, Jan 11, 2010 at 10:43:57AM -0700, Jeremy Conlin wrote:
> I just created some auto properties settings for my repository.  I
> need to now apply these settings to all the files in my repository.
> Is there some automated way to do this or do I have to do it manually?

Look at the propedit and propset subcommands, and the -R flag. Failing
that, find [...] | xargs svn propset [...] or equivalent should be
helpful.

tyler

Re: Question about excessive mergeinfo

[Stein Somers]

I think SVN wants you to not copy the file/dir but instead to merge the
revision where it was added to the branch.


Interesting idea, but as far as I get it it seems a complicated process:
 - In the WC's target directory, merge a part of the changeset that 
created (or last moved) the wanted subdirectory. So now we're no longer 
only merging root directories.
 - Inside the new subdirectory, merge the rest of the history of the 
source subdirectory.


And why would SVN not like copies? Forget that I wrote "from another 
branch", it happens inside a branch too (i.e. if the only active 
mergeinfo is in a parent directory shared by source and target of the 
copy). If you do a simple WC -> WC copy, you get no additional 
mergeinfo. If you do a URL -> WC copy on the same paths and revisions, 
you get explicit/excessive mergeinfo on top. I'm pretty sure that's a 
bug. But never mind, I can elide it myself. We'll see in 1.7.


--
Stein

Re: Adding auto properties after file has been committed

[Larry Shatzer, Jr.]

I've been using
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_apply_autoprops.pyto
do this. It works great.

On Mon, Jan 11, 2010 at 10:35 AM, Jeremy  wrote:

> I have a repository and just enabled/added some auto properties.  How
> can I go back and add these properties to files already committed?  I
> really don't want to do this manually and was hoping there was an
> automated method to do this.
>
> Thanks,
> Jeremy
>

Re: Advice on how to merge bug fix from branch to trunk

[Stein Somers]

On 11/01/2010 18:09, Tyler Roscoe wrote:

The usual way to do this is to make the bugfix on trunk and then
cherrypick merge the change from trunk up to your branch.


Sure, in the early stages of the release process, but near or past 
D-day, as any decent CMM zero team we switch to panic mode. We hotfix 
things in the release branch, and (re)release, then after the dust has 
settled merge back to trunk. And then see what was wrong with the hotfix.


No problem: you just need to record-only a merge of all the early 
revisions of the branch that you _don't_ want to merge back to trunk 
(like changesets that are merges from trunk themselves), and then you're 
set to easily merge all hotfixes back to trunk.


--
Stein

Subversion queries hanging, timing out

[Dave Purrington]

Hello,

Lately we have been experiencing intermittent timeouts with our Subversion
operations. It does not happen initially, but after a while it starts
happening. Restarting Apache alleviates the problem, but it comes back after
a time. As you can imagine, this wreaks havoc.

Our operating environment:

   - server - Windows 2003
   - Apache 2.2.13
   - Subversion server 1.6.3
   - Subversion client 1.6.6
   - mod_auth_sspi 1.0.4-2.0.58
   - 200+ very active users, ~74K files

We have been doing a lot of things to try and mitigate the situation, but to
no avail. Changes have included:

   - tweaking the memory module settings (WinNT MPM)
   - packing the shards
   - trimming hooks down to minimal activity
   - monitoring system resources for spikes (none found, plenty of headroom,
   no queueing, etc)
   - examining the error and access logs (nothing interesting found)

One thing we cannot get much of a view into is the SSPI authentication
module (mod_auth_sspi). It does not seem to have any instrumentation. Has
anyone experienced timeouts or deadlocks with this module? Google isn't
turning up anything interesting. I've viewed the SVN interactions in
Wireshark. A normal sequence of operations is:

   1. client: svn log request
   2. server: 401, authorization required
   3. client: send creds

In the hang scenario, we see just the initial client request (#1). Does this
help or hurt the theory that the mod_auth_sspi/AD interaction is causing the
problem? My next idea is to allow anonymous read access to the repo, which
may help prove that the authentication mechanism is someone responsible. If
nothing else, it should improve the performance.

Lastly, it might be worth mentioning that I have exposed the same SVN repo
on two different endpoints in Apache. That is, I have two location elements
(with different paths) but they both point to the same repo path. Is there
any problem with doing this?

Thanks for reading. Please let me know if you have any ideas.

Regards,
Dave Purrington

SVN Client Very Slow on Windows Compared to Linux

[Andrea Rosso]

Hi,

I've been a long time user of SVN but am running into a strange performance
issue with Windows that I cannot figure out.

I have a 1.6.6 SVN Server running on Debian Linux (Sparc). I've created a
repository with about 10,000 files taking up about 130Mb (website with lots
of small files like dojo, cake, etc.). I'm serving out the repository via
apache 2.2 over http and https (I ultimately want https but am trying http
to see if there are any differences) and there repos is password protected.

On a Fedora Core 11 machine running the SVN 1.6.6 client (over the
internet), the check out of the entire repository runs fine. I don't expect
it to be blazing fast over the internet but the files being checked
out consistently scroll across my window and I can get the whole repository
in a reasonable amount of time.

On a Windows XP Machine and Windows Vista Machine running the SVN 1.6.6
Command line client, on the same network as the Fedora Core 11 machine, I
consistently get very slow performance. The checkout starts out fast, but
then slows down considerably. It seems like the files are checked out in
batches, and that each batch gets slower and slower. I don't get very far in
the check out when each batch takes more than 1-2 minutes (a batch seems to
contain maybe 10-15 files) and gets slower and slower.

I've run strace on the server and all I can tell is that the server is
waiting to write out to the socket. Both client and server aren't using any
CPU and memory is fine. Windows machines are not running anti-virus or
indexing.

I've tried this over http and https and even though http is slightly faster
it has the same behaviour.

I've tried svn+ssh using TortoiseSVN and with that I see better performance
but I'd prefer to use https (http and https in TortoiseSVN are also slow
like the command line).

I used to have this repository on Fedora Core 5 but I don't remember the
exact version (I think it might have been 1.4.2) and I did not run into
these problems. Unfortunately that machine is gone so I can't compare.

I've tried the 1.4.2 SVN Server (started with that and then upgraded it to
1.6.6). I've also tried the 1.5.3 and 1.4.5 svn command line clients and
have the same issues.

What could this be? It seems to be some sort of hand shake issue between
client and server. Maybe there is some tweaking in the Apache config that
needs to be done for windows clients?

Thanks,

Andrea

svn rm should be 'fixed'

[Mahi Haile]

I really like svn. I use it everyday.

But I really dislike 'svn rm', because I make the mistake everyday. I always
want to remove something from the repository and use it, but end up deleting
the file on the local machine. Especially bad when I just added the file, or
there are changes on it I have not saved yet.

I have come to think of it more as a bug than a feature. I think 'svn rm'
should do just that -- rm from the repository rather than the local file as
well.

Thank you,

Re: Advice on how to merge bug fix from branch to trunk

[Tyler Roscoe]

On Mon, Jan 11, 2010 at 07:54:34PM +0100, Stein Somers wrote:
> On 11/01/2010 18:09, Tyler Roscoe wrote:
> >The usual way to do this is to make the bugfix on trunk and then
> >cherrypick merge the change from trunk up to your branch.
> 
> Sure, in the early stages of the release process, but near or past 
> D-day, as any decent CMM zero team we switch to panic mode. We hotfix 
> things in the release branch, and (re)release, then after the dust has 
> settled merge back to trunk. And then see what was wrong with the hotfix.

And I'm sure you never lose track of any "hotfixes" done in this way.

There are a lot of things you *can* do to solve this problem. I'm simply
stating what I think is the accepted best practice. Caveat coder, etc.
etc.

tyler

adding a file to a working copy

[deostroll]

I do a checkout of an empty project

$ svn checkout URL mydir

Q1. So does this make mydir a working copy...?

I try to add a file located elsewhere in the filesystem to mydir

$ cd mydir
$ svn add /home/sample.txt

I get a message saying its added. However the following ends up blank
(shows no output)

$ svn status

Q2. Shouldn't svn status show something here? Why does it not show
anything?

--deostroll

RE: adding a file to a working copy

[Bob Archer]

> I do a checkout of an empty project
> 
> $ svn checkout URL mydir
> 
> Q1. So does this make mydir a working copy...?
> 
> I try to add a file located elsewhere in the filesystem to mydir
> 
> $ cd mydir
> $ svn add /home/sample.txt
> 
> I get a message saying its added. However the following ends up
> blank
> (shows no output)

Hmmm... you should get and error. Since /home/sample.txt is most likely not in 
mydir.


> 
> $ svn status
> 
> Q2. Shouldn't svn status show something here? Why does it not show
> anything?
> 
> --deostroll

Because sample.txt needs to be in mydir or below it.

BOb

RE: svn rm should be 'fixed'

[Bob Archer]

Well, if the file is in the repository you can still get it out. I really don't 
see anything broken here. Because something doesn't work the way you think it 
should I really don't think means it's a bug.

From: Mahi Haile [mailto:begin.middle@gmail.com]
Sent: Monday, January 11, 2010 2:13 PM
To: users@subversion.apache.org
Subject: svn rm should be 'fixed'

I really like svn. I use it everyday.

But I really dislike 'svn rm', because I make the mistake everyday. I always 
want to remove something from the repository and use it, but end up deleting 
the file on the local machine. Especially bad when I just added the file, or 
there are changes on it I have not saved yet.

I have come to think of it more as a bug than a feature. I think 'svn rm' 
should do just that -- rm from the repository rather than the local file as 
well.

Thank you,

RE: svn rm should be 'fixed'

[Bob Archer]

You can also use:

svn rm --keep-local

BOb


From: Mahi Haile [mailto:begin.middle@gmail.com]
Sent: Monday, January 11, 2010 2:13 PM
To: users@subversion.apache.org
Subject: svn rm should be 'fixed'

I really like svn. I use it everyday.

But I really dislike 'svn rm', because I make the mistake everyday. I always 
want to remove something from the repository and use it, but end up deleting 
the file on the local machine. Especially bad when I just added the file, or 
there are changes on it I have not saved yet.

I have come to think of it more as a bug than a feature. I think 'svn rm' 
should do just that -- rm from the repository rather than the local file as 
well.

Thank you,

Assertion failed:svn_path_is_canonical(path, pool) with https

[skrishnam...@bloomberg.com]

Hi,

I configured apache 2.2 with mod_svn for subversion 1.6 and it worked fine with 
http and it worked fine. but with https, I get the below error. Could someone 
help figure out the bug?:
Code:


Assertion failed: svn_path_is_canonical(path, pool), file subversion/libsvn_subr
/path.c, line 380, function svn_path_basename
[Tue Dec 29 10:56:11 2009] [notice] child pid 737 exit signal Abort (6), 
possible coredump in /bb/tmp/apache.2.2



my config for svn in the httpd.conf looks like the below:
Code:


   
  DAV svn
  SVNPath /tmp/repos/
  AuthzSVNAccessFile /temp/repos/conf/authz
   
Require valid-user
  
  AuthType VAS
  AuthName "Please use toolkit username/password to authenticate."
  Require valid-user
  AuthVasUseBasic on





my authz config file looks like the below:
Code:


[groups]
admins = neil, dphung2, rmenon, pdoidge, abeniwal, jrodgers, skrish
smile = kzhang, ssisskin

[/]
@admins = rw
* = r

[/ISYS]
@admins = rw
* = r

[/ISYS/Apps]
* = rw


[/quote]

Re: Subversion queries hanging, timing out

[Rob van Oostrum]

Does mod_auth_sspi rely on persistent connections to the AD? Does
mod_auth_sspi use a connection pool and/or rely on persistent connections to
the AD? I've come across timeout issues like this with LDAP/AD integrations,
where the AD admins would not allow persistent connections, which would
break SVN once all the connections in the pool were dead, and mod_ldap
wouldn't recover from this (by knowing to drop and refresh dead
connections).

Hope that helps,

R.

On Mon, Jan 11, 2010 at 2:25 PM, Dave Purrington
wrote:

> Hello,
>
> Lately we have been experiencing intermittent timeouts with our Subversion
> operations. It does not happen initially, but after a while it starts
> happening. Restarting Apache alleviates the problem, but it comes back after
> a time. As you can imagine, this wreaks havoc.
>
> Our operating environment:
>
>- server - Windows 2003
>- Apache 2.2.13
>- Subversion server 1.6.3
>- Subversion client 1.6.6
>- mod_auth_sspi 1.0.4-2.0.58
>- 200+ very active users, ~74K files
>
> We have been doing a lot of things to try and mitigate the situation, but
> to no avail. Changes have included:
>
>- tweaking the memory module settings (WinNT MPM)
>- packing the shards
>- trimming hooks down to minimal activity
>- monitoring system resources for spikes (none found, plenty of
>headroom, no queueing, etc)
>- examining the error and access logs (nothing interesting found)
>
> One thing we cannot get much of a view into is the SSPI authentication
> module (mod_auth_sspi). It does not seem to have any instrumentation. Has
> anyone experienced timeouts or deadlocks with this module? Google isn't
> turning up anything interesting. I've viewed the SVN interactions in
> Wireshark. A normal sequence of operations is:
>
>1. client: svn log request
>2. server: 401, authorization required
>3. client: send creds
>
> In the hang scenario, we see just the initial client request (#1). Does
> this help or hurt the theory that the mod_auth_sspi/AD interaction is
> causing the problem? My next idea is to allow anonymous read access to the
> repo, which may help prove that the authentication mechanism is someone
> responsible. If nothing else, it should improve the performance.
>
> Lastly, it might be worth mentioning that I have exposed the same SVN repo
> on two different endpoints in Apache. That is, I have two location elements
> (with different paths) but they both point to the same repo path. Is there
> any problem with doing this?
>
> Thanks for reading. Please let me know if you have any ideas.
>
> Regards,
> Dave Purrington
>
>

Unable to change a commit message

[Kari McNair]

I'm trying to remove an invalid character from the end of a commit message. All 
the correct hooks are invoked but when I use...

$ svn propset -r 671 --revprop svn:log "message" URL

...the command prompt window just hangs. I tried changing the message through 
TortoiseSVN but when I go to save the new message, it freezes. I've even just 
tried editing it from a Mac through Terminal and that just hangs as well. 
Anyone have any other ideas?

Kari McNair

RE: svn: MERGE of '/svn//shelvesets': 409 Conflict ()

[Kriv, Larry (HC Product Technology)]

 Johan,

The mystery is solved.  Our original problem was resolved by the server 
re-boot.  Not sure why, but be that as it may ...

The second problem resulted from a typo in the pre-commit.cmd file, which was 
edited while we were debugging the original problem.  

Bad code in pre-commit.cmd:  %~dp0SubversionHook.exe" pre-commit %1 %2 %svnbin%
Good code in pre-commit.cmd:  "%~dp0SubversionHook.exe" pre-commit %1 %2 
%svnbin% 

Note the missing double-quote in the bad code.  Everything appears to be 
working now.  Thank you for your assistance.

Larry

Larry Kriv
Email larry.k...@hp.com   




-Original Message-
From: Kriv, Larry (HC Product Technology) 
Sent: Friday, January 08, 2010 8:45 AM
To: 'Johan Corveleyn'
Cc: users@subversion.apache.org; Buczkowski, Joel
Subject: RE: svn: MERGE of '/svn//shelvesets': 409 Conflict 
()

Johan,

Thanks for your response.  The double-slashes seem to be an artifact of a 
cut-paste out of an IM session log.  Looking at the actual error, there are 
only single slashes there.  

I am attempting to narrow down where in the hook there error is springing from 
before I send you any snippets.  

Larry 


Larry Kriv
Email larry.k...@hp.com   




-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com] 
Sent: Friday, January 08, 2010 6:12 AM
To: Kriv, Larry (HC Product Technology)
Cc: users@subversion.apache.org; Buczkowski, Joel
Subject: Re: svn: MERGE of '/svn//shelvesets': 409 Conflict 
()

On Thu, Jan 7, 2010 at 11:47 PM, Kriv, Larry (HC Product Technology)
 wrote:
>
> OS:  Windows Server 2003 R2.  Client Server: Windows XP Professional 2002, SP 
> 2
> SVN version 1.6.3, File System repository structure
> Built custom pre- and post-commit hooks, which make various svn calls to 
> examine transaction, allow the commit, then examing the revision to extract 
> information for future use.
> The version of Berkeley DB you're running Subversion with, if any
> Using variouse IDEs with client plug-ins such as TortoiseSVN, JDeveloper 11g, 
> Eclipse, etc.  All of these IDEs support SVN 1.6.
>
> We have several repositories that have been running under VisualSVN Server 
> Manager 2.0.4 since October 2009.  Multiple users have been accessing this 
> repository without any major issues.
> Yesterday, I, as Subversion Administrator, attempted to create a new folder 
> using Tortoise SVN 1.6.6.  I was not able to do so, receiving a 403 error.  
> After several other administrators
> received the same error, we restarted the SVN server, then the server box 
> itself.  Now we are receiving the following message when we try to create a 
> new folder:
>
> org.tigris.subversion.svnclientadapter.SVNClientException: 
> org.tigris.subversion.javahl.ClientException: svn: Commit blocked by 
> pre-commit hook (exit code 123) with output:
> The filename, directory name, or volume label syntax is incorrect.
> svn: MERGE of '/svn//shelvesets': 409 Conflict ()
>     at 
> org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.mkdir(AbstractJhlClientAdapter.java:2310)
>     at 
> org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.mkdir(AbstractJhlClientAdapter.java:896)
>     at 
> oracle.jdevimpl.vcs.svn.op.SVNOperationNewRemoteDir$NewRemoteDirTask.executeMkdirWithProgress(SVNOperationNewRemoteDir.java:342)
>     at 
> oracle.jdevimpl.vcs.svn.op.SVNOperationNewRemoteDir$NewRemoteDirTask.run(SVNOperationNewRemoteDir.java:223)
>     at java.lang.Thread.run(Thread.java:619)
> Caused by: org.tigris.subversion.javahl.ClientException: svn: Commit blocked 
> by pre-commit hook (exit code 123) with output:
> The filename, directory name, or volume label syntax is incorrect.
> svn: MERGE of '/svnshelvesets': 409 Conflict 
> ()
>     at 
> org.tigris.subversion.javahl.JavaHLObjectFactory.throwException(JavaHLObjectFactory.java:777)
>     at 
> org.tmatesoft.svn.core.javahl.SVNClientImpl.throwException(SVNClientImpl.java:1850)
>     at 
> org.tmatesoft.svn.core.javahl.SVNClientImpl.mkdir(SVNClientImpl.java:836)
>     at 
> org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.mkdir(AbstractJhlClientAdapter.java:2307)
>     ... 4 more
> Caused by: org.tmatesoft.svn.core.SVNException: svn: Commit blocked by 
> pre-commit hook (exit code 123) with output:
> The filename, directory name, or volume label syntax is incorrect.
> svn: MERGE of '/svnshelvesets': 409 Conflict 
> ()
>     at 
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
>     at 
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
>     at 
> org.tmatesoft.svn.core.internal.io.dav.DAVCommitEditor.closeEdit(DAVCommitEditor.java:373)
>     at 
> org.tmatesoft.svn.core.wc.SVNCommitClient.doMkDir(SVNCommitClient.java:480)
>     at 
> org.tmatesoft.svn.core.javahl.SVNClientImpl.mkdir(SVNClientImpl.java:834)
>     ... 5 more
>
>
> When we comm

RE: Advice on how to merge bug fix from branch to trunk

[Srilakshmanan, Lakshman]

Hi Jean,

The process we follow is as follows.

All changes & bugFixes are done from branch. 
Trunk is used as a stable version.

Steps.
1) Create branch from trunk
2) Perform your change in the branch.
3) Merge changes from trunk to branch since the branch was taken. (A
change/bugFix could take several weeks before released into production)
4) Merge branch back into trunk (re-integrate).
5) Tag trunk
6) release from Tag

The above solved most of our problems, with one exception. 

A change in trunk, not yet released into production, and a priority one
bugFix is required. We take a branch from the previous Tag and perform
the bugFix. Tag the branch and release into production to resolve the
emergency. 

This situation is very rare and if this situation arises then extreme
care need to be exercised to merge this fix into trunk and a new tag
created from trunk and released into production.

  

Thanks 
Lakshman
-Original Message-
From: Jean Seurin [mailto:jean.eastc...@gmail.com] 
Sent: Monday, 11 January 2010 8:51 PM
To: users@subversion.apache.org
Subject: Advice on how to merge bug fix from branch to trunk

Hi,

we have a problem we can't solve yet with Subversion.
In our process, we create a branch of a version that is going to be
released. Then we release from that branch and create a tag for each
released version.

The problem lies in the bug fix of this released version. We have to
apply manually the fix to the branch, release a new tag, and then report
the same modification to the trunk.

Developer are really loath to do that. They have enough pression to fix
the bug quickly, not to take some more to keep the process consistant.

I have to find a way to facilitate this bug porting from branch to
trunk.

Unfortunately I can't find any merge example made with this
configuration. It seems it's designed to work the other way, trunk ->
branch.

I'd be interested in others people use of SVN to support their release
process.
Is there a way to get that bug porting made easy with some merge
command?

best rgds,
Jean

Troubles with VirtualHost configuration: never asked for password

[Will Scheidegger]

Dear subversion users

I'm having a hard time configuring my virtual host to restrict access to my 
subversion repository. This is what my conf looks like:

#Virtual Host Configuration


ServerName svn.domain.com


Order Allow,Deny
Allow from all

DAV svn
SVNPath /usr/local/svn/myproject
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/subversion/passwd
Require valid-user




Without the "Order Allow,Deny" + "Allow from all" directive the default virtual 
host configuration takes over and access is denied ("Server sent unexpected 
return value (403 Forbidden) in response to OPTIONS request..."). But with the 
directives I'm never asked for a password. According to all the manuals I 
consulted on the web, this setup _should_ challenge the user for a password 
(stored in /etc/subversion/passwd). Do I need to configure something else, i.e. 
modify stuff in /usr/local/svn/myproject/conf?

Thanks!

-will

RE: svn 1.6 client echoes password

[Patrick Oor]

Hi Stefan.

Thanks for your tip. I recompiled my client using the "dependency package" [1]. 
This way, I got the right APR installation, and my client no longer echoes the 
password when I type it. 

Issue resolved.

- Patrick

1. http://svn.collab.net/repos/svn/trunk/INSTALL

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: Tuesday, January 05, 2010 3:13 PM
To: Patrick Oor
Cc: users@subversion.apache.org
Subject: Re: svn 1.6 client echoes password

On Tue, Jan 05, 2010 at 02:25:00PM +0100, Patrick Oor wrote:
> When I switched my SVN client on Red Hat Linux 4 from SVN 1.5.4 to
> 1.6.3 I found out that the newer SVN client echoes my password to the
> screen when I type it. I looked for a fix on the internet (including
> this project) but have not found anything yet. Who can help? Why is
> SVN echoing the password and how can I switch it off again?

Subversion relies on APR to read passwords without echoing.
So this must be a problem with APR, not Subversion.

Check your APR installation.
If the APR compilation process does not detect a getpass(),
getpassphrase(), or getpass_r() routine, or the termios.h
header file, then APR stupidly falls back to reading the password
with a simple fgets() call. This might explain your situation.

The above is valid for APR-1.3.x. I haven't checked other versions.

Stefan

Re: svn rm should be 'fixed'

[Blair Zajac]

Plus it won't delete the file if there are local modifications in it.

I don't think the behavior is wrong, BTW.  If I delete a file then I don't want 
it to be there and compile against it.  It would also be inconsistent with other 
commands.  svn mv does a move both in svn and the filesystem and then rm wouldn't.


Regards,
Blair

--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies

Subversion training, consulting and support
http://www.orcaware.com/svn/

Bob Archer wrote:

You can also use:

 


svn rm --keep-local

 


BOb

 

 


*From:* Mahi Haile [mailto:begin.middle@gmail.com]
*Sent:* Monday, January 11, 2010 2:13 PM
*To:* users@subversion.apache.org
*Subject:* svn rm should be 'fixed'

 


I really like svn. I use it everyday.

 

But I really dislike 'svn rm', because I make the mistake everyday. I 
always want to remove something from the repository and use it, but end 
up deleting the file on the local machine. Especially bad when I just 
added the file, or there are changes on it I have not saved yet.


 

I have come to think of it more as a bug than a feature. I think 'svn 
rm' should do just that -- rm from the repository rather than the local 
file as well.


 


Thank you,

Re: Advice on how to merge bug fix from branch to trunk

[Jean Seurin]

That's more like what we do :)

Actually I was just troubled with the merge possibilities. I've started 
to use the merge function recently, and at the same time discovered the 
--reintegrate option with the feature branches.

I though maybe there could be something equivalent for release branches.
Now that I feel more familiar with the merge command I'll do manual 
merge of bug-fixes from release branch back to trunk.


Thanks Lakshman for sharing your process.
We use feature branch for heavy refactoring sometimes. In this case the 
--reintegrate option makes it easier. Subversion has a feature that is 
supporting this branch merge back to trunk.
But we don't release from trunk. We do release branch as well. And 
that's where the hotfix problem occurs.


cheers
jean

Stein Somers wrote:

On 11/01/2010 18:09, Tyler Roscoe wrote:

The usual way to do this is to make the bugfix on trunk and then
cherrypick merge the change from trunk up to your branch. 


Sure, in the early stages of the release process, but near or past 
D-day, as any decent CMM zero team we switch to panic mode. We hotfix 
things in the release branch, and (re)release, then after the dust has 
settled merge back to trunk. And then see what was wrong with the hotfix.


No problem: you just need to record-only a merge of all the early 
revisions of the branch that you _don't_ want to merge back to trunk 
(like changesets that are merges from trunk themselves), and then 
you're set to easily merge all hotfixes back to trunk. 

Version of a single file

[deostroll]

Is it possible to get the version of a single file inside a repo?

--deostroll

Re: Version of a single file

[Blair Zajac]

deostroll wrote:

Is it possible to get the version of a single file inside a repo?


What do you mean by "version"?

You can use "svn info" on a URL to the file.

Blair

--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies

Subversion training, consulting and support
http://www.orcaware.com/svn/

svn15-shlibs package dependencies

[capmac]

I'm having trouble installing.  Mac Mini Intel Core Duo running OS X 10.6.2:


> mini-Core-Duo:~ adminkoff$ fink install svn15-shlibs
> Password:
> Information about 3342 packages read in 2 seconds.
> The following package will be installed or updated:
>  svn15-shlibs
> The following 11 additional packages will be installed:
>  db48-aes libaprutil.0-dev libaprutil.0-shlibs neon27 neon27-shlibs
>  openldap24-dev openldap24-shlibs readline5 sqlite3-dev sqlite3-shlibs texinfo
> Do you want to continue? [Y/n] n
> Failed: Package requirements not satisfied
> mini-Core-Duo:~ adminkoff$ fink install db48-aes
> Information about 3342 packages read in 0 seconds.
> The following package will be installed or updated:
>  db48-aes
> Reading buildlock packages...
> /sw/bin/dpkg-lockwait -i 
> /sw/fink/dists/stable/crypto/binary-darwin-i386/db48-aes_4.8.24-1_darwin-i386.deb
> Selecting previously deselected package db48-aes.
> dpkg: considering removing db47-aes in favour of db48-aes ...
> dpkg: yes, will remove db47-aes in favour of db48-aes.
> (Reading database ... 13191 files and directories currently installed.)
> Unpacking db48-aes (from .../db48-aes_4.8.24-1_darwin-i386.deb) ...
> Setting up db48-aes (4.8.24-1) ...
> mini-Core-Duo:~ adminkoff$ fink install svn15-shlibs
> Information about 3342 packages read in 1 seconds.
> The following package will be installed or updated:
>  svn15-shlibs
> The following 11 additional packages will be installed:
>  db47-aes libaprutil.0-dev libaprutil.0-shlibs neon27 neon27-shlibs
>  openldap24-dev openldap24-shlibs readline5 sqlite3-dev sqlite3-shlibs texinfo
> Do you want to continue? [Y/n] n
> Failed: Package requirements not satisfied
> mini-Core-Duo:~ adminkoff$ fink install db47-aes
> Information about 3342 packages read in 1 seconds.
> The following package will be installed or updated:
>  db47-aes
> Reading buildlock packages...
> /sw/bin/dpkg-lockwait -i 
> /sw/fink/dists/stable/crypto/binary-darwin-i386/db47-aes_4.7.25-5_darwin-i386.deb
> Selecting previously deselected package db47-aes.
> dpkg: considering removing db48-aes in favour of db47-aes ...
> dpkg: yes, will remove db48-aes in favour of db47-aes.
> (Reading database ... 13206 files and directories currently installed.)
> Unpacking db47-aes (from .../db47-aes_4.7.25-5_darwin-i386.deb) ...
> Setting up db47-aes (4.7.25-5) ...
> mini-Core-Duo:~ adminkoff$ fink install svn15-shlibs
> Information about 3342 packages read in 0 seconds.
> The following package will be installed or updated:
>  svn15-shlibs
> The following 11 additional packages will be installed:
>  db48-aes libaprutil.0-dev libaprutil.0-shlibs neon27 neon27-shlibs
>  openldap24-dev openldap24-shlibs readline5 sqlite3-dev sqlite3-shlibs texinfo
> Do you want to continue? [Y/n] 

etc.

Can anybody help?

Thanks!

reuse of tag to keep stable URLs?

[Brian H. Toby]

I am trying to get beyond my rather simple use of svn and would like  
some advice. My goal is to have two releases of a package available,  
one bleeding edge and the other stable. I want to keep the URLs to  
both releases stable. This seems like a reasonably common thing that  
one would want, but google has failed to find this discussed (probably  
because I am using the wrong lingo to describe what I want.) Anyway, I  
can see two ways to implement this:


1) Keep the bleeding-edge release in the trunk and use a tagged  
version for the stable release. When I am ready to make a new stable  
release, I delete the stable tagged release from the repository and  
then copy the trunk reusing the same tag name.


2) keep the stable release as the trunk and work on the bleeding-edge  
release as a branch. When I am ready to make a new stable release, I  
use merge --reintegrate and commit to update the stable release and  
then delete and recreate the  bleeding-edge branch.


Option 2 seems to be the way that svn is designed to be used, but is  
more complex. I guess it is more robust, if someone commits a change  
to the stable. Are there any other reasons to go that route? Is there  
an even better choice?


Brian