Re: cannot create directory in /db/transactions/

[Thorsten Schöning]

Guten Tag Michael Chen,
am Dienstag, 2. August 2011 um 03:04 schrieben Sie:

> all seem right, but he cannot write into the directory, why?

Do you have something like SELinux or AppArmor running?

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoen...@am-soft.de
Web: http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow

Re: Integration of SVN and Bugzilla 3.2

[Thorsten Schöning]

Guten Tag Nico Kadel-Garcia,
am Montag, 1. August 2011 um 23:34 schrieben Sie:

> Bugzilla is perl based, not even compiled. So anything is *possible*.
> It's not built-in, but a fast Google search turns up this add-on:

>  http://freshmeat.net/projects/scmbug/

Depending on your needs, and Bugzilla version .3.2 is too old,
Bugzilla provides extensions for integration with source code
management. Those integrations seem to primary show commits at their
Bugs, SCMBug has more to give like log checking, own mail sending
capabilities, product checkings and a lot of other stuff. SCMBug adds
comments with the log infos, while the extensions don't. I find both
ways interesting, but am using SCMBug at the moment, because comments
are searchable, and can relatively easy be linkified etc.

http://code.google.com/p/bugzilla-vcs/

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoen...@am-soft.de
Web: http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow

Re: Do svn:externals changes need to be committed to work?

[Geoff Hoffman]

Hey André,

On Mon, Aug 1, 2011 at 6:54 PM, André Hänsel  wrote:

> I am trying to add an svn:externals definition to a working copy. I set the
> property on a directory and ran svn update on that directory, but nothing
> is
> fetched.
>

One of my favorite topics.

svn:externals is tricky to understand and use at first but very powerful and
worth learning.

The syntax is

svn propset svn:externals 'A B' C

Where:
 A is the name of the folder you want your external reference checked out
into (created);
 B is the URL to the external repository dir you want to reference in the
current working dir;
 C is the path to the local working dir folder on which you want to set the
svn:externals property

I think you created the folder first - let your externals definition create
the folder 'A'.

An example (from [2])

svn propset svn:externals 'akismet
http://plugins.svn.wordpress.org/akismet/trunk' .


Note the dot at the end. In this example, the svn:externals property is
being set on the current folder (probably htdocs/wp-plugins - just a hunch)

What most examples don't show you is to cd into the directory you want to
set the property on first then call it '.'  (no quotes, dot = current dir)

Also the SVN Book[1] says because this property is multi-line, better off
using svn editor (vi) versus trying it all on the command line as it is
"extra tricky" to do this way.

You can see why this is important; if you wanted to load all the wp-plugins
from their source repos you would need multiple svn:externals set on the
wp-plugins dir, one for akismet, another for w3 total cache, and so on. It
is *very* easy to accidentally erase all of the previously set externals
definitions if you try this on the command line.

Due to this I strongly recommend to use your IDE to load the existing
property value, edit it as desired, then save/set/apply/update.


I found this article:
> http://blogs.gnome.org/johannes/2008/02/20/svnexternals-for-noobs/
> However, from other documentation it's unclear to me if a commit is really
> necessary for svn:external to work. Of course, I don't want to commit an
> untested external definition.
>
> I am using TortoiseSVN 1.6.15 built with Subversion 1.6.16.
>


The order is, you apply the property with propset (you have just modified
only the property of the directory, nothing else.)
Svn status shows you '.' is modified. or 'wp-plugins' is modified.
Next, do an svn update. Your content from external repo defined, comes
streaming down, and `akismet` folder is created in
htdocs/wp-plugins/akismet.
Svn status still shows you only '.' is modified. or 'wp-plugins' is
modified.
Now, commit - only the dir props are commited

If your external code is also your own code (your own shared library in
another repo you control, for example) be very careful when changing stuff
in [working copy] and [external code] in same commit. Most IDEs will let you
do this, but warn 'You're about to commit to multiple repositories...' This
may be exactly what you want, but often it is not.


I recommend reading these

[1] http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html

[2]
http://beerpla.net/2009/06/20/how-to-properly-set-svn-svnexternals-property-in-svn-command-line/

HTH -

AW: Read-Only file systems (Was: Worst Error Message?)

[Markus Schaber]

Hi,


Von: Stefan Sperling [mailto:s...@elego.de]
> > It is written in SVN book that repository that uses FSFS should work
> > on read-only media.
> > Is it something that was broken recently?
> >
> > - see "Usable from a read-only mount" row in the table in the middle
> > of
> >
> > http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html
> 
> Sorry, I was mistaken there.
> On IRC Bert Huijben and Daniel Shahaf corrected me:
> 
>  stsp: (re: users@) read only operations on a fsfs repository
don't
> obtain a lock (and don't need write access). Only commit and revprop
> changes should need write access. (I don't know what is required for
bdb).
> We don't use read locks, except for the sqlite (and maybe bdb) builtin
> ones.
>  stsp: and packing

But AFAIR, V1.7 uses sqlite in the repository. Does that change
anything?
 

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 

Re: Do svn:externals changes need to be committed to work?

[Stefan Sperling]

On Tue, Aug 02, 2011 at 03:54:23AM +0200, André Hänsel wrote:
> I am trying to add an svn:externals definition to a working copy. I set the
> property on a directory and ran svn update on that directory, but nothing is
> fetched.
> 
> I found this article:
> http://blogs.gnome.org/johannes/2008/02/20/svnexternals-for-noobs/
> However, from other documentation it's unclear to me if a commit is really
> necessary for svn:external to work. Of course, I don't want to commit an
> untested external definition.
> 
> I am using TortoiseSVN 1.6.15 built with Subversion 1.6.16.

With Subversion 1.6, if you put the svn:externals property on a locally
added directory you'll need to commit the directory before 'svn update'
will fetch the externals.

This has been fixed in Subversion 1.7, see:
http://subversion.tigris.org/issues/show_bug.cgi?id=2267

You can try out a pre-release version of 1.7 if you need this feature ASAP.
http://subversion.apache.org/packages.html#pre-release
If you do so, please help improve the final 1.7.0 release by reporting
any problems you find while using the pre-release version. Thanks!

Re: Read-Only file systems (Was: Worst Error Message?)

[Stefan Sperling]

On Tue, Aug 02, 2011 at 10:09:06AM +0200, Markus Schaber wrote:
> >  stsp: (re: users@) read only operations on a fsfs repository
> don't
> > obtain a lock (and don't need write access). Only commit and revprop
> > changes should need write access. (I don't know what is required for
> bdb).
> > We don't use read locks, except for the sqlite (and maybe bdb) builtin
> > ones.
> >  stsp: and packing
> 
> But AFAIR, V1.7 uses sqlite in the repository. Does that change
> anything?

The sqlite db is used for the revprop packing feature.
This feature is only used at commit time. You cannot commit to a
read-only repository anyway :)

Subversion 1.6 uses sqlite for this, too, not just 1.7.

AW: Do svn:externals changes need to be committed to work?

[Markus Schaber]

Hi, André,

Von: André Hänsel [mailto:an...@webkr.de]
> I am trying to add an svn:externals definition to a working copy. I set
> the property on a directory and ran svn update on that directory, but
> nothing is fetched.
> 
> I found this article:
> http://blogs.gnome.org/johannes/2008/02/20/svnexternals-for-noobs/
> However, from other documentation it's unclear to me if a commit is really
> necessary for svn:external to work. Of course, I don't want to commit an
> untested external definition.
> 
> I am using TortoiseSVN 1.6.15 built with Subversion 1.6.16.

>From my experience with Subversion 1.6, the directory needs to be committed, 
>but not the svn:external definition itsself.

So maybe you can commit the empty directory, and then add the externals 
properties and test them before committing them.

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 

RE: upgrading source code in local repository

[Brecht Ameije]

On Monday 1 Aug 2011, Ulrich Eckhardt wrote:
> On Friday 29 July 2011, Brecht Ameije wrote:
> > I read the referred page in the book, indeed: the script
svn_load_dirs.pl
> > is exactly what I need. It implements the steps that I did by hand.
> 
> There is one thing that took me a while to understand when starting to use
> that: This doesn't preserve your local changes. Instead, after uploading a
new
> upstream version, you have to apply your local changes again. Merging
helps
> though.
> 
> > But when I try it, I doesn't work as flawless as I thought it would:
> > It dumps a list with all added/deleted files and gives each of them a
> > number.
> > Than you have to manually connect the correct numbers to say which ones
> > are actually renamed files. A very tedious job, as there are +100
different
> > files and the lists aren't even sorted alphabetically :(
> 
> I agree. If you know Perl, you might come up with something
different/better
> or just more suitable for your case.

That's the nice thing about scripts. Maybe one day...

> 
> > Running /usr/bin/svn add -N --targets
> > /tmp/svn_load_dirs_W1GIx88wmF/targets.1
> > /usr/bin/svn_load_dirs.pl: /usr/bin/svn add -N --targets
> > /tmp/svn_load_dirs_W1GIx88wmF/targets.1 failed with this output:
> > svn: warning: 'TODO_unicode@' not found
> > svn: warning: 'include/ar.h@' not found
> 
> The at sign has a special meaning in SVN URL, it is used for peg
revisions.
> Question is, are there files with a trailing at sign in the tree that you
want
> to import? If yes, they are not handled correctly. If not, wrong filenames
> have been generated at some point. It is probably a bug either in the
import
> script or SVN itself.

The original file names don't have the at sign in them. It must be atted by
the script ;)

> 
> > Cleaning up /tmp/svn_load_dirs_W1GIx88wmF
> > (in cleanup) cannot chdir to
> > /tmp/svn_load_dirs_W1GIx88wmF/my_import_wc from
> > /tmp/svn_load_dirs_W1GIx88wmF: No such file or directory, aborting. at
> > /usr/bin/svn_load_dirs.pl line 2056
> 
> This looks strange. I know I had issues with virus scanners during
imports,
> but I never managed to fully explain why and when.

No virus scanner here.

> 
> > The 'not found' files, are actually the files that are added in the new
> > vendor version.
> 
> Those with the trailing "@"?

Yep. But again, they don't have the at in their name.

> 
> > The 'no such file or dir' is in one of the two renamed folders
> > ('archival/libarchive') that I marked for renaming...
> > Seem like the script is looking for them in my working copy, but they
don't
> > exist (yet).
> 
> The script is checking out a working copy, then copying the version to be
> imported over it. For any missing/added files, it then prompts you if
those
> were new file or if they were moved etc. It then performs the according
"svn
> add/move/delete" calls and commits the new version. It shouldn't be
looking
> for anything in already existing working copies - did you perhaps run it
> inside a working copy?
> 
> Uli 
Hmm, true, I was running it inside a working copy. So I hoped that would be
be the issue. But after running it again from another dir, I noticed 2
things:
- the problem persists: the script aborts with the same errors
- before aborting, aparently the script had already committed all rename
actions.

So I guess the script acts in 2 stages:
1. The script is checking out a working copy. Before copying the version to
be
imported over it, it will check both versions for any missing/added files,
and
prompt you if those were new files or if they were moved etc. It then
performs
the according "svn rename" calls and commits the renames.
2. Only now the script wil copy the version to be imported over the working
copy.
And then it will commit these changes.

For me stage 1 worked nicely, the errors happened in stage 2.
Stage 2 is easy to do by hand, so that's what I did.

Conclusion:
The script is not much better than doing it all by hand. It's possibly
more usefull on smaller projects. So taking the bugs (at-signs, others?)
out,
and making the file-compare prompt easier to handle would really be an
improvement.


Thanks all for the input.
Also thanks to Andreas and Stefan. I'll leave Git to the professionals ;)

Brecht

Re: Read-Only file systems (Was: Worst Error Message?)

[Daniel Shahaf]

Stefan Sperling wrote on Tue, Aug 02, 2011 at 10:22:23 +0200:
> On Tue, Aug 02, 2011 at 10:09:06AM +0200, Markus Schaber wrote:
> > >  stsp: (re: users@) read only operations on a fsfs repository
> > don't
> > > obtain a lock (and don't need write access). Only commit and revprop
> > > changes should need write access. (I don't know what is required for
> > bdb).
> > > We don't use read locks, except for the sqlite (and maybe bdb) builtin
> > > ones.
> > >  stsp: and packing
> > 

The short answer is "read-only access doesn't require a writeable
mount".

The revprop packing feature /of Subversion 1.8/ will continue to
maintain this invariant.  (The 1.7-dev incarnation of the feature
didn't, but it has been removed and won't be released.)

> > But AFAIR, V1.7 uses sqlite in the repository. Does that change
> > anything?
> 
> The sqlite db is used for the revprop packing feature.

s/revprop packing/rep-sharing/

> This feature is only used at commit time. You cannot commit to a
> read-only repository anyway :)
> 

To clarify: the rep-sharing SQLite DB is only accessed during commits.

Though, there is a standing backport for svn_fs_verify() which would
break that...  I'll follow up on dev@.

> Subversion 1.6 uses sqlite for this, too, not just 1.7.

RE: Do svn:externals changes need to be committed to work?

[Bert Huijben]

> -Original Message-
> From: Markus Schaber [mailto:m.scha...@3s-software.com]
> Sent: dinsdag 2 augustus 2011 10:27
> To: André Hänsel; users@subversion.apache.org
> Subject: AW: Do svn:externals changes need to be committed to work?
> 
> Hi, André,
> 
> Von: André Hänsel [mailto:an...@webkr.de]
> > I am trying to add an svn:externals definition to a working copy. I set
> > the property on a directory and ran svn update on that directory, but
> > nothing is fetched.
> >
> > I found this article:
> > http://blogs.gnome.org/johannes/2008/02/20/svnexternals-for-noobs/
> > However, from other documentation it's unclear to me if a commit is
really
> > necessary for svn:external to work. Of course, I don't want to commit an
> > untested external definition.
> >
> > I am using TortoiseSVN 1.6.15 built with Subversion 1.6.16.
> 
> From my experience with Subversion 1.6, the directory needs to be
> committed, but not the svn:external definition itsself.
> 
> So maybe you can commit the empty directory, and then add the externals
> properties and test them before committing them.

In Subversion 1.7 externals definitions don't have to be committed to work
correctly. In 1.6 I would recommend committing them before applying, but in
many cases it will work if you don't do that.


We integrated the tracking of which externals a working copy has in the new
working copy store. The next 'svn update' will apply the changes even if the
directory on which they are defined was never committed.

Bert

Re: Read-Only file systems (Was: Worst Error Message?)

[Daniel Shahaf]

Daniel Shahaf wrote on Tue, Aug 02, 2011 at 13:25:18 +0300:
> Though, there is a standing backport for svn_fs_verify() which would
> break that...  I'll follow up on dev@.

Actually, a quick test tells me that it's possible to read an SQLite
database that lives on a read-only mount.

Naturally, that test doesn't imply that the same observation is true in
general.

http://www.sqlite.org/lockingv3.html

Re: how to back svn repositories

[Nico Kadel-Garcia]

On Tue, Aug 2, 2011 at 2:07 AM, zhiwei chen  wrote:
> hi,everyone.
> We have many svn repositories,more than 100,000 , but every repository has
> less than 1024M.
> So,which svn backup strategies should I use ?

Great bird of space, what are you running? Sourceforge? You're
approaching 100 TB of repository space!!!

I have to assume that 99.9% of these are idle auto-generated
repositories created as part of sme regression testing or continuous
build  structure. I went through something like this with an in-house
backup system that used a database to manage hardlinks, and most of
whose directories had no actual edits or unlocked files in them. I had
to optimize it by basically ignoring all the non-active equivalent of
tags, which turned it from an insane 5 day restoration procedure to a
2 hour restoration procedure.

I assume that the old, stable repositories are what most of us would
use as tags: suitable to lock down and backup up with rsync, star, or
a similar tool that will not re-copy every byte every time you run it,
that can be run twice without overwriting already transmitted files,
and that can be gracefully managed to select or deselect targets. This
will mirror not only the revisiions, but the file ownership,
authentication and scripting internal to the repository. It won't
mirror HTTP access or web configs, or SSH based access configurations,
so treat that separately.

That said, the databases can be synchronized with svnsync on a remote
server for efficiency, and to help avoid corruption issues from
mirroring files in the midst of database interactions. This will *not*
gain you fail over repositories with identical uuid's suitable for
"svn switch" operations, but it will also allow you to update your
backup server's subversion binaries without interfering with the
primary system.. Any repository that has had updates since the last
svnsync, svnadmin dump, or other backup technology, however, will be
prone to "split-brain" problems where a new revision submitted on the
failover or recovered server does not match the revision previously
with the same number on the original server, and chaos will ensue.

Split-brain is something that people don't seem to worry about much
for small repositories: you can notify your clients that they need to
re-checkout their working copies and copy over their working files,
and they'll only lose some recent commits. But it's potentially
really, really nasty to automated procedures.

Frankly, this is the point where you call WanDisco and say "Hi, I've
got a problem: do you have a commercial grade solution?" They have
tools that will do multi-master setups and avoid the "split-brain"
problem, and have probably already addressed the backup needs.

Re: how to back svn repositories

[Nico Kadel-Garcia]

On Tue, Aug 2, 2011 at 2:26 AM, Venkata Badipatla
 wrote:
> Svnadmin dump utility is a correct strategy to be followed. As you are
> telling many repos, you can write simple perl script which can create the
> dump files for all the repos.

OK, *now* I'm going to waggle my finger at you.  I find this typical
of some ancient and simplistic perl "solutions" I've seen lately where
a "simple matter of programming" turned into a "simple matter of
ignoring the realities".

Writing a "simple perl script" to chew through 100,000 repositories,
all approaching 1 Gig in size, is approaching 100 TB of fata. Even
with fast local disk, it's a very significant hardware load on the
server. 100 TB, at 80 MB/second for reasonably fast modern disk
is.  2 weeks. And it would easily take that long to restore, and
it is going to *CHURN* the backups, so identical backups still get
overwritten rather than checked and left alone. And it is *begging*
for "split-brain" problems, where changes that occur in the 2 weeks
are in people's working copies but not in the failover or slave
repository and chaos ensues when their working copy has changes
committed, with the same revision, that the new master server does not
have.

It will also entirely neglect all configuration files, such as
pre-commit and post-commit scripts.

One *could* do something with svnadmin dump of incremental changes:
some sort of flag to register where previous successful transfers left
off could be used to begin dumps with only the updates, and preserve
those. It gets tricky to maintain. But that's all builit right into
svnsync, anyway, so one might as well use that to strart with rather
than this simplistic approach. If you need to stay this simple for
whatever reason, an svnsync push from the primary server might serve.


>
> --Venkat
>
> From: zhiwei chen [mailto:zhiw...@gmail.com]
> Sent: Tuesday, August 02, 2011 11:38 AM
> To: users@subversion.apache.org
> Subject: how to back svn repositories
>
>
>
> hi,everyone.
>
>
>
> We have many svn repositories,more than 100,000 , but every repository has
> less than 1024M.
>
>
>
> So,which svn backup strategies should I use ?
>
> DISCLAIMER == This e-mail may contain privileged and confidential
> information which is the property of Persistent Systems Ltd. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Persistent Systems Ltd. does not accept any liability for
> virus infected mails.

Strange behavior on directory delete/commit

[Dominik Psenner]

Hi,

having a fresh subversion repository doing this as preparation:

$ mkdir foo/
$ svn add foo
$ svn commit -m "test"
Adding  foo
Revision X sent.
$ rmdir foo
$ svn st
!   foo
$ svn delete foo
D   foo

And finally this command fails:

$ svn commit foo -m "fail"
svn: entry "foo" has no URL

This instead does work:

$ svn commit -m "works"
Delete  foo
Revision X sent.

svn commit behaves inconsistently depending on whether a PATH argument is
given or not. If it is a bug, it should get at least priority P2 because one
is unable to commit partial changes to the WC as in this scenario:

$ mkdir foo/
$ svn add foo
A   foo
$ svn commit -m "test"
Adding  foo
Revision X sent.
$ rmdir foo
$ svn st
!   foo
$ svn delete foo
D   foo
$ touch bar
$ touch foobar
$ svn add bar foobar
A   bar
A   foobar
$ svn commit foo bar
svn: entry "foo" has no URL

To get things done, one would have to backup foobar somewhere, revert
foobar, do the commit without PATH arguments and copy foobar over to the WC.
*eek*

Let me know what you think about this!

Greetings,
D.

AW: Strange behavior on directory delete/commit

[Becker, Thomas]

You could also delete the directory directly in the repository using "svn 
delete  -m ". This way you would avoid the problem of committing 
partial changes of your working copy.

Regards,
  Thomas

-Ursprüngliche Nachricht-
Von: Dominik Psenner [mailto:dpsen...@gmail.com] 
Gesendet: Dienstag, 2. August 2011 08:41
An: users@subversion.apache.org
Betreff: Strange behavior on directory delete/commit

[...]

To get things done, one would have to backup foobar somewhere, revert
foobar, do the commit without PATH arguments and copy foobar over to the WC.
*eek*

Let me know what you think about this!

Greetings,
D.



 

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed 
are solely those of the author and do not necessarily represent those of Torex 
(Torex Group of Companies). If you are not the intended recipient of this email 
and its attachments, you must take no action based upon them, nor must you copy 
or show them to anyone.  Please contact the sender if you believe you have 
received 
this email in error.

Torex Retail Solutions GmbH
Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg.
UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749.
Geschäftsführer: Stephen Callaghan, Martin Timmann.


.

Re: Strange behavior on directory delete/commit

[Giulio Troccoli]

On 02/08/11 07:40, Dominik Psenner wrote:

Hi,

having a fresh subversion repository doing this as preparation:

$ mkdir foo/
$ svn add foo
$ svn commit -m "test"
Adding  foo
Revision X sent.
$ rmdir foo
$ svn st
!   foo
$ svn delete foo
D   foo

And finally this command fails:

$ svn commit foo -m "fail"
svn: entry "foo" has no URL

This instead does work:

$ svn commit -m "works"
Delete  foo
Revision X sent.

svn commit behaves inconsistently depending on whether a PATH argument is
given or not. If it is a bug, it should get at least priority P2 because one
is unable to commit partial changes to the WC as in this scenario:

$ mkdir foo/
$ svn add foo
A   foo
$ svn commit -m "test"
Adding  foo
Revision X sent.
$ rmdir foo
$ svn st
!   foo
$ svn delete foo
D   foo
$ touch bar
$ touch foobar
$ svn add bar foobar
A   bar
A   foobar
$ svn commit foo bar
svn: entry "foo" has no URL

To get things done, one would have to backup foobar somewhere, revert
foobar, do the commit without PATH arguments and copy foobar over to the WC.
*eek*

Let me know what you think about this!

Greetings,
D.

I think SVN is behaving correctly. When you do svn commit foo you're 
telling Subversion to commit changes made in foo. There are no changes 
in foo because it's been deleted. The changes, instead, are in its 
parent directory, the one from where you issued your commands. That's 
why svn commi works, it assumes . as the path.

Problems merging missed range

[K.L.]

Hi,

I tried to reintegrate branch, but svn said that some files in branch
miss range from trunk.
Tried to fix but range merge seems not working with urls.
So I backed up branch, deleted it, created with the same name and
overrode with backup. Committed branch, reintegrated, merged with
record-only and committed again.
Then tried to reintegrate one more time just for test. And those files
with missed ranges from old branch showed up in merge again though no
change were made to them along the way.
Any ideas what's happening?

Thanks

RE: how to back svn repositories

[Bob Archer]

> hi,everyone.
> 
> We have many svn repositories,more than 100,000 , but every
> repository has less than 1024M.
> 
> So,which svn backup strategies should I use ?

I think there are three basic options...

1. Back up to tape... this is what we do. Yes, we possible lose intra day stuff 
but it is a risk we are taking.

2. use svnadmin hotcopy to copy the repos to a separate drive system.

3. use svnsync to mirror all the repositories. This also gives you a psuedo hot 
swap situation. Of course, you have to have the hardware available to do it, so 
this is probably the most expensive option.

Yes, very basic level answer I know.

BOb

Re: Svn Searcher

[Michael Diers]

On 2011-07-27 17:18, Phil Pinkerton wrote:
> Anyone have experience installing and using Svn Searcher ?
> 
> http://svn-search.sourceforge.net/
> 
> I have a client that would like to do Repository Searches.

Other tools that offer repository indexing and searching:

 * Atlassian FishEye
   http://www.atlassian.com/software/fisheye/

 * Subversion Repository Search Engine (SupoSE)
   http://www.supose.org/

 * SvnQuery
   http://svnquery.tigris.org/

-- 
Michael Diers, elego Software Solutions GmbH, http://www.elego.de

AW: Do svn:externals changes need to be committed to work?

[André Hänsel]

Stefan Sperling wrote:
> 
> On Tue, Aug 02, 2011 at 03:54:23AM +0200, André Hänsel wrote:
> > I am trying to add an svn:externals definition to a working copy. I
> > set the property on a directory and ran svn update on that directory,
> > but nothing is fetched.
> >
> > I found this article:
> > http://blogs.gnome.org/johannes/2008/02/20/svnexternals-for-noobs/
> > However, from other documentation it's unclear to me if a commit is
> > really necessary for svn:external to work. Of course, I don't want to
> > commit an untested external definition.
> >
> > I am using TortoiseSVN 1.6.15 built with Subversion 1.6.16.
> 
> With Subversion 1.6, if you put the svn:externals property on a locally
> added directory you'll need to commit the directory before 'svn update'
> will fetch the externals.
> 
> This has been fixed in Subversion 1.7, see:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2267

Uh, thanks. That's it, I didn't commit the folder before creationg the
property.

Subversion transactions within post-commit

[Ray Rashif]

Hi list

I've been stumped by this issue for months. I had never enough time to
troubleshoot it, so I'm finally desperate after having spent an entire
day trying to figure things out.

We have a _local_ checkout of the repository on our server, and our
post-commit hook needs to run svn-add, svn-rm and svn-ci commands in
that checkout. All of these commands run fine. For eg. (within the
post-commit script):

echo "Updating..."
svn up

would yield:

Updating...
Updated to revision $whatever.

And:

echo "Adding..."
svn add

would output:

Adding...
A $whatever

Now comes the interesting part. As soon as I add a commit transaction,
say, AFTER those commands, ALL of them FAIL at the SAME TIME:

echo "Updating.."
svn up
echo "Adding..."
svn add $whatever
echo "Committing..."
svn ci -m "$whatever"

gives us:

Updating...
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
Adding...
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
Committing...
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

Notes:

* It is always reproducible. I just remove the commit command from the
script and everything works as expected.

* The owner of the checked out repo is a normal user of the web
account, but post-commit is run by 'apache'.

* We have the repo chown'ed to $user:$user and perms set to 775.

* The user 'apache' is also part of the group $user, but the user
$user is _not_ part of the group 'apache' (not possible for security
reasons on the server).

* As such, both the currently logged in user and 'apache' can at least
do update transactions without any errors.

Another very important note:

* Since post-commit runs as 'apache', some Subversion files (not sure
which) are created with perms 444.

Would appreciate some help in this matter. Thanks!


--
GPG/PGP ID: 19BAA7AD

Re: Subversion transactions within post-commit

[David Weintraub]

On Tue, Aug 2, 2011 at 4:03 PM, Ray Rashif  wrote:
> We have a _local_ checkout of the repository on our server, and our
> post-commit hook needs to run svn-add, svn-rm and svn-ci commands in
> that checkout. All of these commands run fine. For eg. (within the
> post-commit script):

NO! NO! NO! AUUUGGGHHH!

Never update a repository with a hook.! That's why you're given the
relatively safe "svnlook" command. It allows you to look, but not
touch a repository.

Think of it this way, the user must wait until the post-commit hook
finishes. So, that means the user must wait until you've updated your
working directory, manipulated what you need, and then commit those
changes back.

Besides, there's the issue of recursion. Your hook script does a
commit which runs another hook script which runs another commit.

And, then there's the issue of a user making a set of changes, and
finding out that their working directory is out of date with changes
they didn't make.

Finally, there's the Finger 'o Blame which is dying to point to the
scapegoat who messed things up. You want the Finger 'o Blame to point
to the user who committed the transaction. Otherwise, you end up with
this:

Boss: Dammit, we have to delay the release and miss the release date.
Why was the code messed up?

Developer: It wasn't my fault. It worked on my machine. It was that
stupid post-commit hook that CM put on! It broke my code.

See, Finger o' Blame points right at you.

You didn't say what you're doing and why, so I can't say how you want
to do it. However, these usually fall into the category of "fixing"
the committed files. For example, you want to reformat the code to be
in the correct format. Instead, either put this as part of a
pre-commit trigger and simply fail the commit, or use a continuous
build system like Hudson or Jenkins to test the situation.

For example, users are suppose to run checkstyle on their code before
committing. You want to run checkstyle and fix the code. Instead, have
Jenkins or Hudson run Checkstyle, then mark the revision as bad and
email the user if checkstyle finds issues. Jenkins/Hudson will email
the user.

> Now comes the interesting part. As soon as I add a commit transaction,
> say, AFTER those commands, ALL of them FAIL at the SAME TIME:
>
> echo "Updating.."
> svn up
> echo "Adding..."
> svn add $whatever
> echo "Committing..."
> svn ci -m "$whatever"
>
> gives us:
>
> Updating...
> svn: Working copy '.' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
> Adding...
> svn: Working copy '.' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
> Committing...
> svn: Working copy '.' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

Well, the repository is locked because another user is in the middle
of a commit transaction, and you're attempting to do another commit.
Although it is a post-commit hook, and the repository is already
modified, the commit is still going on.

See:



for more information.

-- 
David Weintraub
qazw...@gmail.com

RE: Integration of SVN and Bugzilla 3.2

[Wang, HarryX C]

We are in the process of upgrading to v3.6 or later. 
Thank you for the information.  

Harry W. 

-Original Message-
From: Thorsten Schöning [mailto:tschoen...@am-soft.de] 
Sent: Tuesday, August 02, 2011 12:16 AM
To: users@
Subject: Re: Integration of SVN and Bugzilla 3.2

Guten Tag Nico Kadel-Garcia,
am Montag, 1. August 2011 um 23:34 schrieben Sie:

> Bugzilla is perl based, not even compiled. So anything is *possible*.
> It's not built-in, but a fast Google search turns up this add-on:

>  http://freshmeat.net/projects/scmbug/

Depending on your needs, and Bugzilla version 3.2 is too old,
Bugzilla provides extensions for integration with source code
management. Those integrations seem to primary show commits at their
Bugs, SCMBug has more to give like log checking, own mail sending
capabilities, product checkings and a lot of other stuff. SCMBug adds
comments with the log infos, while the extensions don't. I find both
ways interesting, but am using SCMBug at the moment, because comments
are searchable, and can relatively easy be linkified etc.

http://code.google.com/p/bugzilla-vcs/

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoen...@am-soft.de
Web: http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow

Re: Subversion transactions within post-commit

[Ray Rashif]

On 3 August 2011 04:37, David Weintraub  wrote:
> NO! NO! NO! AUUUGGGHHH!
>
> Never update a repository with a hook.! That's why you're given the
> relatively safe "svnlook" command. It allows you to look, but not
> touch a repository.
> ...
> SNIP
> ...

Arrrgghhh damn it! Exactly what I feared. Especially the recursion. So
much so that now I think I was in denial all the while.

OK, looks like I have to explain a bit further to clear this up and
hopefully get some solutions.

We use the repository to directly serve some files (so Subversion
updates are immediately reflected). Something like
http://subversion.apache.org/faq.html#website-auto-update

So $files.subdomain.org/public_html is actually a local checkout of
$svn.subdomain.org/public_html/trunk/$somedir, and whenever someone
commits something to the SVN repo, the post-commit hook updates the
local checkout. So anyone browsing the file server will get the most
recent files.

However, we need to be a bit more personal than that. We need to do
some checks on those files and remove ones that should not be there.
We need to do this immediately after the commit, so cron is not an
option. How should we go about doing this?


--
GPG/PGP ID: 19BAA7AD

Re: Subversion transactions within post-commit

[Nico Kadel-Garcia]

On Tue, Aug 2, 2011 at 5:00 PM, Ray Rashif  wrote:
> On 3 August 2011 04:37, David Weintraub  wrote:
>> NO! NO! NO! AUUUGGGHHH!
>>
>> Never update a repository with a hook.! That's why you're given the
>> relatively safe "svnlook" command. It allows you to look, but not
>> touch a repository.
>> ...
>> SNIP
>> ...
>
> Arrrgghhh damn it! Exactly what I feared. Especially the recursion. So
> much so that now I think I was in denial all the while.
>
> OK, looks like I have to explain a bit further to clear this up and
> hopefully get some solutions.
>
> We use the repository to directly serve some files (so Subversion
> updates are immediately reflected). Something like
> http://subversion.apache.org/faq.html#website-auto-update
>
> So $files.subdomain.org/public_html is actually a local checkout of
> $svn.subdomain.org/public_html/trunk/$somedir, and whenever someone
> commits something to the SVN repo, the post-commit hook updates the
> local checkout. So anyone browsing the file server will get the most
> recent files.

That's what "svn checkout" for initial setup, and "svn update" or "svn
revert" of the local copy are for.

> However, we need to be a bit more personal than that. We need to do
> some checks on those files and remove ones that should not be there.
> We need to do this immediately after the commit, so cron is not an
> option. How should we go about doing this?

Then you do your updates in a working copy as part of a working copy,
and that copy has a deployment script or "Makefile" that does "rsync"
or other mirroring tools to publish those changes to your exposed
website. I like "Makefile" bassed approaches, myself, so I can do
"make", "make test", and "make install".
>
> --
> GPG/PGP ID: 19BAA7AD
>

Re: Subversion transactions within post-commit

[Ray Rashif]

On 3 August 2011 05:47, Nico Kadel-Garcia  wrote:
> That's what "svn checkout" for initial setup, and "svn update" or "svn
> revert" of the local copy are for.

We already have that working, I just outlined the current setup:

http://files.foobar.org/ is a direct file mirror (less revision
control; plus additional files generated post-commit dependent on the
latest version of each revision controlled file) of
http://svn.foobar.org/trunk/somewhere.

Developers push stuff to somewhere (which is private in Subversion).
This private area then gets served as HTTP/FTP, edited appropriately
for public use (and also for programs as some of the files generated
after a commit are databases).

> Then you do your updates in a working copy as part of a working copy,
> and that copy has a deployment script or "Makefile" that does "rsync"
> or other mirroring tools to publish those changes to your exposed
> website. I like "Makefile" bassed approaches, myself, so I can do
> "make", "make test", and "make install".

Ahh yes. This was one of our earlier plans, but I scraped that because
it would duplicate the contents (of the SVN repo) on the server. But
let me get this right:

svn commit (anywhere) -> post-commit -> svn up (local checkout), rsync
-> local mirror -> edits ?


--
GPG/PGP ID: 19BAA7AD

Re: Subversion transactions within post-commit

[Nico Kadel-Garcia]

On Tue, Aug 2, 2011 at 6:49 PM, Ray Rashif  wrote:
> On 3 August 2011 05:47, Nico Kadel-Garcia  wrote:
>> That's what "svn checkout" for initial setup, and "svn update" or "svn
>> revert" of the local copy are for.
>
> We already have that working, I just outlined the current setup:
>
> http://files.foobar.org/ is a direct file mirror (less revision
> control; plus additional files generated post-commit dependent on the
> latest version of each revision controlled file) of
> http://svn.foobar.org/trunk/somewhere.
>
> Developers push stuff to somewhere (which is private in Subversion).
> This private area then gets served as HTTP/FTP, edited appropriately
> for public use (and also for programs as some of the files generated
> after a commit are databases).
>
>> Then you do your updates in a working copy as part of a working copy,
>> and that copy has a deployment script or "Makefile" that does "rsync"
>> or other mirroring tools to publish those changes to your exposed
>> website. I like "Makefile" bassed approaches, myself, so I can do
>> "make", "make test", and "make install".
>
> Ahh yes. This was one of our earlier plans, but I scraped that because
> it would duplicate the contents (of the SVN repo) on the server. But
> let me get this right:
>
> svn commit (anywhere) -> post-commit -> svn up (local checkout), rsync
> -> local mirror -> edits ?

Put it in a checklist

1: svn commit (from any authorized user)
2: post-commit publishes updates
I) Create designated working copy, if needed
II) "svn revert" in working copy, to avlid conflicting local
changes overlapping push process
iii) "svn status" in working copy, to report failures or conflicting debris
iv) "svn update" to get relevant updates
v) Edit or generate non-committed local files as needed
vi) Push working copy contents to website with some efficient tool
that does not overwrite correctly published content, such as "rsync"
vii) Leave working copy around for future updates as appropriate

Re: Strange behavior on directory delete/commit

[Ryan Schmidt]

On Aug 2, 2011, at 07:11, Giulio Troccoli wrote:

> On 02/08/11 07:40, Dominik Psenner wrote:
>> 
>> having a fresh subversion repository doing this as preparation:
>> 
>> $ mkdir foo/
>> $ svn add foo
>> $ svn commit -m "test"
>> Adding   foo
>> Revision X sent.
>> $ rmdir foo
>> $ svn st
>> !foo
>> $ svn delete foo
>> Dfoo
>> 
>> And finally this command fails:
>> 
>> $ svn commit foo -m "fail"
>> svn: entry "foo" has no URL
>> 

> I think SVN is behaving correctly. When you do svn commit foo you're telling 
> Subversion to commit changes made in foo. There are no changes in foo because 
> it's been deleted. The changes, instead, are in its parent directory, the one 
> from where you issued your commands. That's why svn commi works, it assumes . 
> as the path.

I think "svn commit foo" would work fine, provided you do not "rmdir foo" 
first; that was your error.

I also have a feeling Subversion 1.7's new working copy arrangement will fix or 
at least change this behavior.

Re: upgrading source code in local repository

[Ryan Schmidt]

On Aug 1, 2011, at 05:31, Ulrich Eckhardt wrote:

> On Friday 29 July 2011, Brecht Ameije wrote:
>> I read the referred page in the book, indeed: the script svn_load_dirs.pl
>> is exactly what I need. It implements the steps that I did by hand.
> 
> There is one thing that took me a while to understand when starting to use 
> that: This doesn't preserve your local changes. Instead, after uploading a 
> new 
> upstream version, you have to apply your local changes again. Merging helps 
> though.

I think perhaps you still misunderstand. Correct, svn_load_dirs.pl does not 
preserve your local changes. That's not its job. You never run svn_load_dirs.pl 
on directories or parts of the repository that contain any changes. You only 
run them on pristine copies of the vendor software.

Example:

svn mkdir $URL/vendor

/vendor in the repository will contain copies of all the third-party software 
you want to keep track of. You will never make your own changes to that code in 
this part of the repository. These will always represent exact copies of the 
upstream source.

Let's say you want to keep track of a third-party software called foo. It's 
currently at version 1.1. You download the tarball of version 1.1 and you 
import it into the repository at this path:

svn mkdir $URL/vendor/foo
svn import /path/to/foo-1.1 $URL/vendor/foo/current

"current" is analogous to the "trunk" of a project that you're developing, but 
it's not called "trunk" here because "trunk" is a place where you make changes, 
and you're not going to be making any changes here.

Now you make a copy of current and call it 1.1:

svn cp $URL/vendor/foo/current $URL/vendor/foo/1.1

This is like a "tag" in a project that you're developing.

Finally, you copy version 1.1 into another location in the repository where you 
want to use it. Let's say that foo will be used inside a project you're 
developing called bar, so perhaps you run:

svn cp $URL/vendor/foo/1.1 $URL/bar/trunk/libs/foo

Now you have a copy of foo 1.1 in the libs directory in the trunk of your bar 
project. You can edit that copy of foo to your heart's content.

Next, imagine a new version 1.2 of foo is released and you want to upgrade the 
foo in the bar project to that verison.

So you download the tarball of foo 1.2 and use svn_load_dirs.pl to update 
$URL/vendor/foo/current to version 1.2. svn_load_dirs.pl will also copy that to 
$URL/vendor/foo/1.2 for you if you ask it to.

Now you can go into your working copy of bar/trunk/libs/foo and run:

svn merge $URL/vendor/foo/1.1 $URL/vendor/foo/1.2 .

That is: You ask subversion to apply changes that occurred between foo 1.1 and 
1.2 to your existing (and possibly modified) copy of foo 1.1. You commit it, 
stating in the message that you updated it to 1.2. Done.


>> Running /usr/bin/svn add -N --targets
>> /tmp/svn_load_dirs_W1GIx88wmF/targets.1
>> /usr/bin/svn_load_dirs.pl: /usr/bin/svn add -N --targets
>> /tmp/svn_load_dirs_W1GIx88wmF/targets.1 failed with this output:
>> svn: warning: 'TODO_unicode@' not found
>> svn: warning: 'include/ar.h@' not found
> 
> The at sign has a special meaning in SVN URL, it is used for peg revisions. 
> Question is, are there files with a trailing at sign in the tree that you 
> want 
> to import? If yes, they are not handled correctly. If not, wrong filenames 
> have been generated at some point. It is probably a bug either in the import 
> script or SVN itself.
> 
> 
>> The 'not found' files, are actually the files that are added in the new
>> vendor version.
> 
> Those with the trailing "@"?


Correct, the @ sign has special meaning in subversion. If a filename has an @ 
in it, subversion will think you are asking for that special meaning and will 
probably not do what you meant. To work around that, you append an @ to the end 
of the filename. That is what the script is probably doing here and why you are 
seeing "@" at the end of each filename. It is not a bug; it is a feature of 
subversion, and a feature of svn_load_dirs.pl that it is trying to handle all 
filenames correctly for you, even those containing an @.

This does not explain why it failed for you though.