date:20101029

Hi,

I'm working with our Web Team to re-engineer their development process. All the
code is already under Subversion, but everything is in one big directory.
They're not using any branch or tags for that matter. And of course, testing is
not as rigorous and controlled as it should be. Anyway, I have suggested the
usual trunk/branches/tags layout.

Developers will normally work on branches, but can occasionally work directly
on trunk for easy and quick fixes. The tester will create a QA branch as a copy
of trunk at a specific revision. When they are happy that a QA is ready for
releasing, a tag is created from the QA (or maybe from trunk again at the same
revision).

I think they will go for such a solution, even though it means that they cannot
pick-and-choose what to test. If they want to test a bug fixed in revision
1000, they will also test all bugs fixed in previous revision.

The problem is that they may want to fast track an urgent bug fix. It shouldn't
happen often, but it may happen so I need to come up with a solution for that
case too.

What I'm thinking is something like the following. Let's supposed that 1.1 is
the latest release, i.e. it's what's in production.
i) the developer creates a branch off the tag
svn cp http:///tags/1.1 http:///branches/1.1_urgent_fix -m"Creating branch fro urgent bug 123456"
ii) the developer makes all the necesary, coding and testing
iii) the fix is merged back to trunk
cd trunk
svn merge ^/branches/1.1_urgent_fix .
svn ci -m"Fixing urgent bug 123456"
iv) the branch goes live
svn cp http:///branches/1.1_urgent_fix http:///tags/1.2 -m"Fixed bug 123456"
switch the production site to point to ^/tags/1.2
v) at this point all the QA are useless because the do not contain the urgent
fix, so a new QA must be created
svn cp -rHEAD http:///trunk http:///tags/QA_1.3_1 -m"Created first QA for 1.3"

Now my questions.
1 - Do you have any comments on the process and/or any suggestions?
2 - Would the merge, in step iii, do the right thing and merge all revisions
committed into the branch into trunk? I can't use --reintegrate becuase I
haven't previously merged from trunk to the branch (as the branch was created
as a copy of a tag).
3 - I don't really like the fact that after the fix has gone live, we are
forced to create a QA from HEAD, which means testing everything that has gone
into trunk, but I can't think of another way to make sure the fix is indeed
included in the Qas and especially in the next (1.3 in this case) release.

Thank you in advance.

Giulio

Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

Re: verification of user id '' not configured

Enrique Porta wrote on Fri, Oct 29, 2010 at 08:17:54 +0200:
> Hi! i have an apache 2.2.15 server and i want to configure a secure folder.
> 
> This is my secure configuration
> 
> 

Try dropping the trailing slash.

> DAV svn
> SVNParentPath /var/lib/svn
> SVNListParentPath On
> 
> AuthType Digest

Add an AuthDigestProvider directive?

> AuthName "Private"
> AuthUserFile /etc/svn-auth-file
> AuthzSVNAccessFile /etc/svn-authz-file
> Require valid-user
>  
> 
> The svn-auth-file are create wit the htdigest command and the "Private" realm 
> .
> 
> The content of the svn-authz-file is: [/] * = r
> 
> The webrowser show me the login window, but on the server error log
> appears this:
> 
> verification of user id '' not configured
> 
> I try using the AuthType Basic with a htpasswd file and all works
> perfectly, but with the Digest no
> 
> What's the problem?
> 
> Thx ;)

Secure Connection Truncated/Insufficient system resources

2010-10-29 Thread Bagnall, Martin

Hi,

I'm getting a lot of errors when performing svn checkouts or updates. On the 
client side they appear as follows:

Error: REPORT of '/svn//!svn/vcc/default': Could not 
read chunk size:
Error: Secure connection truncated

In the Apache SSL error log on the server the corresponding message is:
[Fri Oct 29 13:10:15 2010] [error] [client ] Provider encountered 
an error while streaming a REPORT response.  [500, #0]
[Fri Oct 29 13:10:15 2010] [error] [client ] A failure occurred 
while driving the update report editor  [500, #721450]
[Fri Oct 29 13:10:15 2010] [error] [client ] Can't read file 
'E:\\repositorydb\\revs\\20\\20795': Insufficient system 
resources exist to complete the requested service.

After searching the mailing list archives and google for similar issues I tried 
the following changes:

1)  Added an exclusion on the client side for my workspace folder to the 
Antivirus software

2)  Set "SVNPathAuthz Off" in the server config

3)  Set "Timeout" to 5 in the server config

4)  Set "KeepAliveTimeout" to 25 in the server config

Unfortunately none of them have worked.

The "Insufficient system resources" message suggests a problem with the server 
but I don't see anything hogging memory or CPU and available disk space is 
fine. The repository is quite large if that makes a difference (278 Gb on the 
server).

Server: Apache 2.2.15 with Subversion 1.6.11 on Windows Server 2003
Client: TortoiseSVN 1.6.11 on Windows 7


Any ideas on what else I can try or advice on how I can further debug the 
problem?

Also, what do those numbers at the end of the error lines, e.g. "[500, 
#721450]" mean?

Regards,
Martin Bagnall

Moving to Subversion for PL-SQL development

First of all let me tell you that I don't know much of how PL-SQL development 
works so I might say something really obvious to you or more likely just wrong. 
Please forgive me.

I have a team that uses StarTeam as their VCS and we are now working on moving 
the project to Subversion. We are planning to use an importer for the initial 
load of the repository which seems to do what they want (I'm not looking after 
that part).

I have a problem though with their releasing process.

As I understand it, a major release is formed by all the packages and scripts, 
plus some table initialisation and sometime some data (I presume for defaults 
and stuff like that). Minor releases are done with patches which included only 
the packages that have changed from the previous patch.

So, if I want 5.4.0 (major release), I get everything. I unpack the kit, 
install it, run it, whatever it take and I'm done. If I am already on 5.4.0 and 
I want 5.4.3 (a minor release) I will be sent 3 patches: to 5.4.1, then 5.4.2 
and finally 5.4.3. Apparently I just need to unzip them and I'm done.

Now, I might not be clear in the above process, so if someone with more 
experience with PL-SQL development and release wants to correct me, please do. 
I know there isn't one way to do things, but it's more likely that I understood 
wrong than we are doing it in a special way.

Anyway, if I am right, I'm struggling to come up with a process using 
Subversion. It seems they do not want to tag everything in trunk because that 
would be like a major release (apparently it would include those table and data 
things). Maybe we could re-organised the code to separate the packages from the 
data and then we could tag the packages, which is more what they want. And this 
way, to go to 5.4.3 I won't need 5.4.1 and 5.4.2 at all, which in my opinion is 
even better.

In the end what I am looking for with this email is some advice on how to 
proceed from people with more experience than me in projects using PL-SQL.

Thanks
Giulio Troccoli


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

Re: Secure Connection Truncated/Insufficient system resources

2010-10-29 Thread Johan Corveleyn

On Fri, Oct 29, 2010 at 2:35 PM, Bagnall, Martin
 wrote:
> In the Apache SSL error log on the server the corresponding message is:
>
> [Fri Oct 29 13:10:15 2010] [error] [client ] Provider
> encountered an error while streaming a REPORT response.  [500, #0]
>
> [Fri Oct 29 13:10:15 2010] [error] [client ] A failure occurred
> while driving the update report editor  [500, #721450]
>
> [Fri Oct 29 13:10:15 2010] [error] [client ] Can't read file
> 'E:\\repositorydb\\revs\\20\\20795': Insufficient system
> resources exist to complete the requested service.
>

>
> The “Insufficient system resources” message suggests a problem with the
> server but I don’t see anything hogging memory or CPU and available disk
> space is fine. The repository is quite large if that makes a difference (278
> Gb on the server).

Wow, 278 Gb for a repository is *huge* IMHO. Are there a lot of large
binary files in there?

Maybe the "insufficient resource" is related to the number of open
file handles? I don't know how this works on Windows (or how you can
configure it), but on *nix you have things like "ulimit" to limit the
maximum number of file descriptors a process can have open
simultaneously.

Is there anything special about revision 20795, the one that is
referenced in the "insufficient system resources" message? Is it a
very large rev file in the repository (the file
'E:\\repositorydb\\revs\\20\\20795')?

Cheers,
Johan

>
> Server: Apache 2.2.15 with Subversion 1.6.11 on Windows Server 2003
>
> Client: TortoiseSVN 1.6.11 on Windows 7

RE: Advice on process for web development

CC-ing the list 

> -Original Message-
> From: Luiz Guilherme Kimel [mailto:lki...@dba.com.br] 
> Sent: 29 October 2010 15:44
> To: Giulio Troccoli
> Subject: RES: Advice on process for web development
> 
> Giulio,
> 
> I would recommend you a reference book for SCM patterns. Try 
> ADDISON WESLEY Software Configuration Management Patterns. It 
> has solutions
> 
> Answering your questions, you need to stablish baselines for 
> your software.
> Branches will have one baseline as their common start point, 
> as their "base". This base will usually be a stable version 
> of your software. Let's say your baseline is exactly your 
> current production release.

What you're saying is that the branches should be created as copies of trunk at 
a specific revision, i.e. the production one. Have I understood correctly?

> Sometimes your baseline will evolve. Maybe because your QA 
> team approved some new features for production, maybe because 
> you made urgent corrections.
> If it's approved for production it will be your new baseline. 
> All branches from this baseline will need to be "rebased" 
> before releasing, they need to incorporate any production changes.

So, basically, I need to merge changes in trunk from the previous "production" 
revision to the current "production" revision (which may not be HEAD at all) to 
the branches.

> Your correction will be tested isolated, approved and merged 
> to your trunk for tagging and release. If your development 
> branches are based on the trunk, then you will need to merge 
> trunk changes to each development branch to rebase them. Use 
> the development branch for integration so that the next 
> approved branch will always merge to the trunk with no 
> possibility of conflict. After rebasing, apply new QA tests.

I'm not sure I understand you here.

After the development in a branch has been completed, the branch is tested and 
if approved merged back into the trunk. Surely though I need to test trunk as 
well. I didn't say, but yes when a branch is reintegrated into the trunk, the 
other branches should merge from trunk to get those changes.

> Why your QA team have a branch??? They won't ever make 
> changes, so all they need is a tag. I mean, in SVN it's the 
> samething, but in the concept it's a lot different.

The QA team does not have a branch. I realised I said "create a QA branch as a 
copy of trunk" but then in the command I did create the "branch" in tags. Which 
doesn't mean that they cannot change it, but it will be prevented and, as you 
said, conceptually is different.

> Do you already use any project management and bug tracking 
> tool? If not, I would recommend MantisBT.

We do. It's actually part of what the Web Team does.

Thanks for your input, however, you haven't touched on the main issues I have, 
which is about the case of an urgent fix.

Giulio

> Best Regards,
> Luiz Guilherme M. Kimel
> 
> 
> -Mensagem original-
> De: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com]
> Enviada em: sexta-feira, 29 de outubro de 2010 09:20
> Para: users@subversion.apache.org
> Assunto: Advice on process for web development
> 
> Hi,
> 
> I'm working with our Web Team to re-engineer their 
> development process. All the code is already under 
> Subversion, but everything is in one big directory. They're 
> not using any branch or tags for that matter. And of course, 
> testing is not as rigorous and controlled as it should be. 
> Anyway, I have suggested the usual trunk/branches/tags layout.
> 
> Developers will normally work on branches, but can 
> occasionally work directly on trunk for easy and quick fixes. 
> The tester will create a QA branch as a copy of trunk at a 
> specific revision. When they are happy that a QA is ready for 
> releasing, a tag is created from the QA (or maybe from trunk 
> again at the same revision).
> 
> I think they will go for such a solution, even though it 
> means that they cannot pick-and-choose what to test. If they 
> want to test a bug fixed in revision 1000, they will also 
> test all bugs fixed in previous revision.
> 
> The problem is that they may want to fast track an urgent bug 
> fix. It shouldn't happen often, but it may happen so I need 
> to come up with a solution for that case too.
> 
> What I'm thinking is something like the following. Let's 
> supposed that 1.1 is the latest release, i.e. it's what's in 
> production.
> i) the developer creates a branch off the tag
> svn cp http:///tags/1.1 http:// REPO>/branches/1.1_urgent_fix -m"Creating branch fro urgent 
> bug 123456"
> ii) the developer makes all the necesary, coding and testing
> iii) the fix is merged back to trunk
> cd trunk
> svn merge ^/branches/1.1_urgent_fix .
> svn ci -m"Fixing urgent bug 123456"
> iv) the branch goes live
> svn cp http:///branches/1.1_urgent_fix 
> http:// REPO>/tags/1.2 -m"Fixed bug 123456"
> switch the production site to point to ^/tags/1.2
> v) at th

RES: Moving to Subversion for PL-SQL development

Hi Giulio,

I'm curious about how you manage your PL/SQL development and identify
packages and its versions and how do you manage concurrency. Until were I
know Oracle won't manage concurrency when two developers edit the same
package and once broke, the entire package stop working.

I used, in a past project, to ask the team to save packages as text files in
the repository and lock them to signalize someone is working on it. The live
package being edited should be edited with a different name like
"package_name_plus_developers_user_name" so that the package won't be broken
for other developers. Once the developer finished to edit the package and
make his own tests he would increase its version number (a simple comment in
the package interface and body), write a small changelog as a comment,
submit it to the repository, release de lock, update package with its real
name and delete the temporary one.

Sounds a little troublesome, but I couldn't think of a better process. Later
I included a version function inside each package so I could check packages
versions using an sql script.

"It seems they do not want to tag everything in trunk because that would be
like a major release (apparently it would include those table and data
things). Maybe we could re-organised the code to separate the packages from
the data and then we could tag the packages, which is more what they want."

Yes, you can have a BTT (branch, tags, trunk) structure for the database DDL
including packages, another BTT for documentation and another for source
code and manage their evolution separately if it fits better to your team.

Instead of one big configuration item now you have 3 to care about. The
database definition versions can have patches to update a live database from
version a to version b. 

But anyway you will need to build your high level configuration item, which
will represent your entire software package including database, code,
documentation etc in its specific compatible version. This set, you can
release software.

Your installer can check each configuration item version to decide what to
do (database version updates, documentation version). There are things that
can be just deleted and overwritten (like binaries and help), but database
will usually need to be patched. Having the database and plsql code as an
independent configuration item sounds good to me.

I'm not sure I'm helping... lol


Luiz Guilherme M. Kimel


-Mensagem original-
De: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] 
Enviada em: sexta-feira, 29 de outubro de 2010 10:11
Para: users@subversion.apache.org
Assunto: Moving to Subversion for PL-SQL development

First of all let me tell you that I don't know much of how PL-SQL
development works so I might say something really obvious to you or more
likely just wrong. Please forgive me.

I have a team that uses StarTeam as their VCS and we are now working on
moving the project to Subversion. We are planning to use an importer for the
initial load of the repository which seems to do what they want (I'm not
looking after that part).

I have a problem though with their releasing process.

As I understand it, a major release is formed by all the packages and
scripts, plus some table initialisation and sometime some data (I presume
for defaults and stuff like that). Minor releases are done with patches
which included only the packages that have changed from the previous patch.

So, if I want 5.4.0 (major release), I get everything. I unpack the kit,
install it, run it, whatever it take and I'm done. If I am already on 5.4.0
and I want 5.4.3 (a minor release) I will be sent 3 patches: to 5.4.1, then
5.4.2 and finally 5.4.3. Apparently I just need to unzip them and I'm done.

Now, I might not be clear in the above process, so if someone with more
experience with PL-SQL development and release wants to correct me, please
do. I know there isn't one way to do things, but it's more likely that I
understood wrong than we are doing it in a special way.

Anyway, if I am right, I'm struggling to come up with a process using
Subversion. It seems they do not want to tag everything in trunk because
that would be like a major release (apparently it would include those table
and data things). Maybe we could re-organised the code to separate the
packages from the data and then we could tag the packages, which is more
what they want. And this way, to go to 5.4.3 I won't need 5.4.1 and 5.4.2 at
all, which in my opinion is even better.

In the end what I am looking for with this email is some advice on how to
proceed from people with more experience than me in projects using PL-SQL.

Thanks
Giulio Troccoli


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

Revisions not in chronological order

2010-10-29 Thread Chris Evans

Hi,

My repository is made up of a load of folder loaded from cvs2svn dumps.
These were loaded individually and have overlapping date ranges.
When doing an "svn load" it looks like SVN assigns each commit to the
next revision, regardless of the date the commit occurred.

As a result the rage of revisions created for each of the loads have
overlapping dates and the revisions of the repository are not chronological. 

E.g.

C:\Windows\system32>svn log -v -r 2000 https://svn/svn/repo/

r2000 |  | 2006-07-13 11:41:27 +0100 (Thu, 13 Jul 2006) | 2 lines
Changed paths:
   M /Folder1/file1

Message1





C:\Windows\system32>svn log -v -r 2 https://svn/svn/repo/

r2 |  | 2003-08-19 04:30:07 +0100 (Tue, 19 Aug 2003) | 1 line
Changed paths:
   A /Folder2/file1

Message2




C:\Windows\system32>svn log -v -r 21000 https://svn/svn/repo/

r21000 |  | 2006-05-19 11:55:33 +0100 (Fri, 19 May 2006) | 1 line
Changed paths:
   A /Folder2/file2

Message2




This causes problems for "svn log" and "svn cat" when attempting to get
revisions at a particular date for a folder. SVN will find the lowest numbered
revision for that date, regardless of whether the folder exists for that
revision. e.g.


C:\Windows\system32>svn log -r {2010-07-11} https://svn/svn/repo/Folder3
svn: Unable to find repository location for 'https://svn/svn/repo/Folder3' in 
revision 63506


However there are revisions for that date...


C:\Windows\system32>svn log -r 114691 https://svn/svn/repo/Folder3

r114691 |  | 2010-07-11 11:12:14 +0100 (Sun, 11 Jul 2010) | 2 lines

message 4




I've tried "svndumptool check" to check a dump of the entire repository, but it 
comes back ok.
An "svn load" of the dump seems to keep the same revision numbers and dates.

Is there a way of reorganising the repository to have all revisions in 
chronological order?
How can I avoid this happening in the future?
Or is there some other way for getting round this?


Thanks
Chris

--
Gloucester Research Limited believes the information provided herein is 
reliable. While every care has been taken to ensure accuracy, the information 
is furnished to the recipients with no warranty as to the completeness and 
accuracy of its contents and on condition that any errors or omissions shall 
not be made the basis for any claim, demand or cause for action.
The information in this email is intended only for the named recipient.  If you 
are not the intended recipient please notify us immediately and do not copy, 
distribute or take action based on this e-mail.
All messages sent to and from this email address will be logged by Gloucester 
Research Ltd and are subject to archival storage, monitoring, review and 
disclosure.
Gloucester Research Limited, 5th Floor, Whittington House, 19-30 Alfred Place, 
London WC1E 7EA.
Gloucester Research Limited is a company registered in England and Wales with 
company number 04267560.
--

RE: Revisions not in chronological order

>


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

-Original Message-


> From: Chris Evans [mailto:chris.ev...@gresearch.co.uk]
> Sent: 29 October 2010 15:42
> To: 'users@subversion.apache.org'
> Subject: Revisions not in chronological order
>
> Hi,
>
> My repository is made up of a load of folder loaded from
> cvs2svn dumps.
> These were loaded individually and have overlapping date ranges.
> When doing an "svn load" it looks like SVN assigns each
> commit to the next revision, regardless of the date the
> commit occurred.
>
> As a result the rage of revisions created for each of the
> loads have overlapping dates and the revisions of the
> repository are not chronological.

This is expected behaviour if have loaded two or more dumps into the same 
repository.

I seem to remember there is a tool out there to merge dumps file, but I don't 
remember the name. I don't even know if it would merge them in chronological 
order or not. Google it and see what you can find.

Giulio

Re: Advice on process for web development

2010-10-29 Thread Les Mikesell

On 10/29/2010 9:04 AM, Giulio Troccoli wrote:

Sometimes your baseline will evolve. Maybe because your QA
team approved some new features for production, maybe because
you made urgent corrections.
If it's approved for production it will be your new baseline.
All branches from this baseline will need to be "rebased"
before releasing, they need to incorporate any production changes.

So, basically, I need to merge changes in trunk from the previous "production" revision
to the current "production" revision (which may not be HEAD at all) to the branches.

Or just make different 'cuts' from the trunk to new QA branches, which,
if everything works can be copied unchanged to production tags. If you
have to make changes in QA, you have to make an additional decision as
to whether the fix needed there also applies to the ongoing trunk, and
if so, merge it - or maybe it has already been done on the trunk.

Why your QA team have a branch??? They won't ever make
changes, so all they need is a tag. I mean, in SVN it's the
samething, but in the concept it's a lot different.

If things never change between the cut from trunk and the production
release, what's the point of the QA step? It is possible, in fact
likely, that you'll need changes for a release after the trunk has moved
on to include things you don't want in this release.

The QA team does not have a branch. I realised I said "create a QA branch as a copy of
trunk" but then in the command I did create the "branch" in tags. Which doesn't mean
that they cannot change it, but it will be prevented and, as you said, conceptually is different.

If you made a tag for QA you can always copy it out to a branch after
discovering it needs changes.

Thanks for your input, however, you haven't touched on the main issues I have,
which is about the case of an urgent fix.

If you had a QA branch corresponding to each release, you'd have an
obvious place to make maintenance fixes specific to that release. But
that doesn't solve your problem of making sure the fix also is done in
the trunk - unless you do the work on the trunk and merge to the branch
to add the fix. How you do that needs to be a human decision, not
driven by the process. If the process could solve all your problems you
wouldn't need this urgent fix in the first place, you'd have caught it
in QA. Since it is something unexpected, you need to understand it and
figure out separately how it relates to the now-different trunk.

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

mergeinfo not inherrited when I thought it should

2010-10-29 Thread Pieter-Jan Busschaert

Hello,

In a quick test, we have a project which has the following structure:

/trunk/project/subfolder/file

Next, we create a branch from /trunk/project to

/branches/project/branch1/

We edit file on trunk a first time, changing line1 and commit

Inside branch1, we do a merge from trunk. This creates mergeinfo on
/branches/project/branch1

We edit file on trunk a second time, reverting line1, changing line2 and commit

Inside branch1/subfolder, we do a merge from trunk/subfolder.


This last step ignores the mergeinfo on /branches/project/branch1/ and
merges all revisions again since we made the branch. I thought
inherrited mergeinfo would be used here to see that a first part of
the revision range did not need to be merged again. However, this does
not happen.

The result is that we merge the combination of the 2 edits, which is
only changing line2.
However, we had already merged the change to line1, so the revert on
line1 should have been merged too.

See attachment for a reproduction scenario.

Is this scenario supposed to be handled by SVN ?
We are in a corporate environment, using 1.5.1. Is the above scenario
known to be handled correctly in later versions?
Is it a known issue?
Do I try something which is not supported by SVN?


Kind regards,

Pieter-Jan Busschaert
mkdir mergetest
cd mergetest
mkdir trunk
cd trunk
mkdir subdir
cd subdir
echo "line1 00" > test.txt
echo "" >> test.txt
echo "line2 02" >> test.txt
echo "" >> test.txt
echo "line3 01" >> test.txt
cd ..
cd ..
svn import https:///mergetest
cd ..
rm -rf mergetest
svn co https:///mergetest mergetest
cd mergetest

svn up
svn cp https:///mergetest/trunk https:///mergetest/branch
svn up

cd trunk/subdir
echo "line1 00" > test.txt
echo "" >> test.txt
echo "line2 02" >> test.txt
echo "" >> test.txt
echo "line3 02" >> test.txt
svn ci
cd ../..

cd branch
svn merge https:///mergetest/trunk
svn ci
svn propget svn:mergeinfo .
cd ..

cd trunk/subdir
echo "line1 00" > test.txt
echo "" >> test.txt
echo "line2 03" >> test.txt
echo "" >> test.txt
echo "line3 01" >> test.txt
svn ci
cd ../..

cd branch/subdir
svn propget svn:mergeinfo .
svn propget svn:mergeinfo ..
svn merge https:///mergetest/trunk/subdir
svn propget svn:mergeinfo .
svn propget svn:mergeinfo ..
svn ci
cd ../..

RE: mergeinfo not inherrited when I thought it should

>
> Hello,
>
> In a quick test, we have a project which has the following structure:
>
> /trunk/project/subfolder/file
>
> Next, we create a branch from /trunk/project to
>
> /branches/project/branch1/
>
> We edit file on trunk a first time, changing line1 and commit
>
> Inside branch1, we do a merge from trunk. This creates mergeinfo on
> /branches/project/branch1
>
> We edit file on trunk a second time, reverting line1,
> changing line2 and commit
>
> Inside branch1/subfolder, we do a merge from trunk/subfolder.

Do you mean trunk/project/subfolder here?

Anyway, branch1/subfolder does not have any mergeinfo, since the previous merge 
was done on branch1. So Subversion does not know that you have already merged 
the changes to line 1.

Merges from trunk to branch and vice-versa should always be done from the root 
of the project (in your case branches/project/branch1)
>
> This last step ignores the mergeinfo on
> /branches/project/branch1/ and merges all revisions again
> since we made the branch. I thought inherrited mergeinfo
> would be used here to see that a first part of the revision
> range did not need to be merged again. However, this does not happen.
>
> The result is that we merge the combination of the 2 edits,
> which is only changing line2.
> However, we had already merged the change to line1, so the revert on
> line1 should have been merged too.
>
> See attachment for a reproduction scenario.
>
> Is this scenario supposed to be handled by SVN ?
> We are in a corporate environment, using 1.5.1. Is the above
> scenario known to be handled correctly in later versions?

I don't think so, as I think Subversion did the correct thing, given the 
information it has.

However, I recommend you to push for an upgrade of SVN, as I remember 1.5 was 
not particularly good with merging.

> Is it a known issue?
> Do I try something which is not supported by SVN?
>
>
> Kind regards,
>
> Pieter-Jan Busschaert
>


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

RE: mergeinfo not inherrited when I thought it should

2010-10-29 Thread Bob Archer

> In a quick test, we have a project which has the following
> structure:
> 
> /trunk/project/subfolder/file
> 
> Next, we create a branch from /trunk/project to
> 
> /branches/project/branch1/
> 
> We edit file on trunk a first time, changing line1 and commit
> 
> Inside branch1, we do a merge from trunk. This creates mergeinfo on
> /branches/project/branch1
> 
> We edit file on trunk a second time, reverting line1, changing
> line2 and commit
> 
> Inside branch1/subfolder, we do a merge from trunk/subfolder.
> 
> 
> This last step ignores the mergeinfo on /branches/project/branch1/
> and merges all revisions again since we made the branch. I thought
> inherrited mergeinfo would be used here to see that a first part of
> the revision range did not need to be merged again. However, this
> does not happen.

Did you commit the first merge? 

BTW: To minimize the merge info propgation you really just always merge from 
/trunk/project into your branch. If you only want a specific revision you can 
specify it... but still you want to keep all the mergeinfo in 
/branches/project/branch1 if you can... or else merges will start changing all 
kinds of properties on all your child nodes.


> The result is that we merge the combination of the 2 edits, which
> is only changing line2.
> However, we had already merged the change to line1, so the revert
> on
> line1 should have been merged too.
> 
> See attachment for a reproduction scenario.
> 
> Is this scenario supposed to be handled by SVN ?
> We are in a corporate environment, using 1.5.1. Is the above
> scenario known to be handled correctly in later versions?
> Is it a known issue?

There were many merge issues fixed after 1.5.1.. you should get to the latest 
1.6... or at the very least the latest 1.5.

BOb

RE: Secure Connection Truncated/Insufficient system resources

2010-10-29 Thread Bagnall, Martin

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: 29 October 2010 14:43
> To: Bagnall, Martin
> Cc: users@subversion.apache.org
> Subject: Re: Secure Connection Truncated/Insufficient system resources
> 
> On Fri, Oct 29, 2010 at 2:35 PM, Bagnall, Martin
>  wrote:
> > In the Apache SSL error log on the server the corresponding message
> is:
> >
> > [Fri Oct 29 13:10:15 2010] [error] [client ] Provider
> > encountered an error while streaming a REPORT response.  [500, #0]
> >
> > [Fri Oct 29 13:10:15 2010] [error] [client ] A failure
> occurred
> > while driving the update report editor  [500, #721450]
> >
> > [Fri Oct 29 13:10:15 2010] [error] [client ] Can't read
> file
> > 'E:\\repositorydb\\revs\\20\\20795': Insufficient
> system
> > resources exist to complete the requested service.
> >
> 
> >
> > The "Insufficient system resources" message suggests a problem with
> the
> > server but I don't see anything hogging memory or CPU and available
> disk
> > space is fine. The repository is quite large if that makes a
> difference (278
> > Gb on the server).
> 
> Wow, 278 Gb for a repository is *huge* IMHO. Are there a lot of large
> binary files in there?

Yes, there are a lot of binary files in there. None are particularly large by 
themselves but there are many of them.

> 
> Maybe the "insufficient resource" is related to the number of open
> file handles? I don't know how this works on Windows (or how you can
> configure it), but on *nix you have things like "ulimit" to limit the
> maximum number of file descriptors a process can have open
> simultaneously.

I'm not sure how they work on Windows either but I'll take a look - thanks.

> 
> Is there anything special about revision 20795, the one that is
> referenced in the "insufficient system resources" message? Is it a
> very large rev file in the repository (the file
> 'E:\\repositorydb\\revs\\20\\20795')?

I've checked the revision (and others referenced in similar errors, some from 
other repositories) and they all seem to involve a lot of files - again, none 
of the files are particularly large by themselves but there's a great deal of 
them associated with each commit.

> 
> Cheers,
> Johan
> 
> >
> > Server: Apache 2.2.15 with Subversion 1.6.11 on Windows Server 2003
> >
> > Client: TortoiseSVN 1.6.11 on Windows 7

RE: Revisions not in chronological order

2010-10-29 Thread Jon Foster

Giulio Troccoli wrote:
>> From: Chris Evans [mailto:chris.ev...@gresearch.co.uk]
>> My repository is made up of a load of folder loaded from
>> cvs2svn dumps.
>> These were loaded individually and have overlapping date ranges.
>> When doing an "svn load" it looks like SVN assigns each
>> commit to the next revision, regardless of the date the
>> commit occurred.
>>
>> As a result the rage of revisions created for each of the
>> loads have overlapping dates and the revisions of the
>> repository are not chronological.
>
>This is expected behaviour if have loaded two or more dumps into the
same repository.
>
>I seem to remember there is a tool out there to merge dumps
>file, but I don't remember the name. I don't even know if
>it would merge them in chronological order or not. Google
>it and see what you can find.

http://svn.borg.ch/svndumptool/

Haven't tried it myself, but it claims to do what you want.

Kind regards,

Jon

**
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 Cabot Communications Ltd.

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.

Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232

Co. Registered in England number 02817269

Please contact the sender if you believe you have received this email in error.

**

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

write permission issues with repository hosting

2010-10-29 Thread Polder, Matthew J

Hi,

We're running Subversion 1.6.12 on a Solaris 10 machine and hosting 
repositories on it. Users can create and use repositories via svnadmin and svn 
locally on the Solaris machine via file:///, or they can check in 
and out via TortoiseSVN 1.6.8 on their PC via the http:/// protocol, 
with LDAP verification.

For a while this worked flawlessly, but then the machines were reconfigured and 
we can't get it to work. We can either create and use the repositories locally 
but not through Tortoise (we get the permission denied on txn-current-lock 
error) or we can use Tortoise but then not check in locally (failed due to 
attempt to write a readonly database).

We've read the help on Supporting Multiple Repository Access Methods at 
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.multimethod.html and have 
tried those steps, though we're not sure what user should initially own the 
repository (webservd, daemon?).

If anyone could point to us to further online docs or pointers we'd appreciate 
it!

matthew

Re: Secure Connection Truncated/Insufficient system resources

2010-10-29 Thread kmradke

Johan Corveleyn  wrote on 10/29/2010 08:43:26 AM:
> > In the Apache SSL error log on the server the corresponding message 
is:
> >
> > [Fri Oct 29 13:10:15 2010] [error] [client ] Provider
> > encountered an error while streaming a REPORT response.  [500, #0]
> >
> > [Fri Oct 29 13:10:15 2010] [error] [client ] A failure 
occurred
> > while driving the update report editor  [500, #721450]
> >
> > [Fri Oct 29 13:10:15 2010] [error] [client ] Can't read 
file
> > 'E:\\repositorydb\\revs\\20\\20795': Insufficient 
system
> > resources exist to complete the requested service.
> >
> 
> >
> > The ?Insufficient system resources? message suggests a problem with 
the
> > server but I don?t see anything hogging memory or CPU and available 
disk
> > space is fine. The repository is quite large if that makes a 
difference (278
> > Gb on the server).
> 
> Wow, 278 Gb for a repository is *huge* IMHO. Are there a lot of large
> binary files in there?

One would wish this to be true.  I have many >300GB...

> Maybe the "insufficient resource" is related to the number of open
> file handles? I don't know how this works on Windows (or how you can
> configure it), but on *nix you have things like "ulimit" to limit the
> maximum number of file descriptors a process can have open
> simultaneously.
> 
> Is there anything special about revision 20795, the one that is
> referenced in the "insufficient system resources" message? Is it a
> very large rev file in the repository (the file
> 'E:\\repositorydb\\revs\\20\\20795')?

Is the repository packed?  I also was fairly regularly seeing this error
after I packed a large number of repositories on a windows server.
(Not sure that was related since I did see it less frequently
before the packing.  SAN vendors were changed and I also bumped up
the mod_dav version a few minor revs near same time.)  The error is
not always on the same repository nor even on the same revision or
pack file.  In most cases when this error occurs I was unable to
login to a new session on the server.  It seems that Windows 2003
(and before) has some fixed size memory buffers that can cause
this problem.

You can take a look at:

http://support.microsoft.com/kb/935649

(There are other kb articles that apply as well.  Just google
for the mentioned registry keys.)

Reconfiguring the mentioned registry keys seems to have
helped this server.  It does require a reboot and the usual
disclaimer that making changes with regedit could completely
disable your machine applies...

Server 2008 supposedly dynamically allocates these paged memory
pools, so upgrading may also help.

Kevin R.

RES: Advice on process for web development

Let me try explain it better...

Let's say I just built the first version of an application, so I don't
currently have any branch, just the trunk where a small team of developers
were working until now. Our last build was tagged as 1.0.0.54 meaning it's
our 54 build of the 1.0 version. The QA team approved this build and it
becomes our first release of the software. Tag 1.0.0.54 is our baseline
which is equal to our trunk at that moment.

Now we have two new modules to develop in parallel. The team will receive
more people to speed up next releases, so we decided to start working with
branches. Two new branches are created: /branches/1.1a and /branches/1.1b.
Trunk is locked. Only reading is allowed. Developers are allowed to write
only on branches.

Team 1 tags the build 1.1a.12 and Team 2 tags the build 1.1b.5 for testing.
QA approves 1.1b.5 as a release candidate with partial planned functionality
that our client will test. Development continues on both branches.

5 bugs in production are identified. We find that 2 of them are critical and
3 are not and will take some time to fix. We plan for two correction
releases, one for 2 days and another for 5 days. So we start only one new
branche called 1.0.1 both copied from tag 1.0.0.54.

Build 1.0.1.5 delivers planned fixes for version 1.0.1 and is approved for
releasing by the QA team. This tag is then merged into trunk with no
conflicts since there are no other changes committed to the trunk. Version
1.0.1.5 becomes our new baseline, which is reflected in trunk.

Branches 1.1a and 1.1b are now outdated and need to be rebased to include
changes to the baseline. Team 2 (1.1b) stops development and merge trunk
changes to its branch. Team 1 decides not to rebase now and development
continues. Client approved release candidate 1.1b.5 and wants it to go for
production with the partial functionality built.

Team 2 already made changes to 1.1.b branch. So they open a new branch
1.1.1.0 from tag 1.1.b.5 and merge the trunk to it. Team 2 notifies QA that
changes are not conflicting. QA makes regretion tests and finds no problem.
Branch 1.1.1.0 is merged to trunk and tag 1.1.1.0 is created. Software is
release to the client for final tests. Client approves it and the release
goes for production with new functionality.

Team 2 is up to date in it's 1.1b branch, Team 1 keeps apart from production
updates. Team 1 finishes developing their new features and gets build
1.1a.0.23 approved by QA functional tests. Now Team 1 decides to rebase
their work and merge the current trunk content to their 1.1a branch. They
solve conflicts and run unit tests OK. Since version 1.1 was already
released, they now copy their 1.1a branch to tag 1.2.0.24 and asks QA to
rerun all planned tests. Few bug fixes later, client tests OK, build
1.2.0.28 becomes the new release for production. 

Changes applied to the trunk, branch 1.1a is deleted. Second fix package
finishes and build 1.2.1.0 is released. Trunk is updated once again. Team 2
decides to stop development, rename its branch to 1.3 and rebases it with
current trunk version. Next functional release will be 1.3 finishing all
planned development for this software.

Life goes on...

What you think?




-Mensagem original-
De: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] 
Enviada em: sexta-feira, 29 de outubro de 2010 11:05
Para: 'lki...@dba.com.br'
Cc: 'users@subversion.apache.org'
Assunto: RE: Advice on process for web development

CC-ing the list 

> -Original Message-
> From: Luiz Guilherme Kimel [mailto:lki...@dba.com.br] 
> Sent: 29 October 2010 15:44
> To: Giulio Troccoli
> Subject: RES: Advice on process for web development
> 
> Giulio,
> 
> I would recommend you a reference book for SCM patterns. Try 
> ADDISON WESLEY Software Configuration Management Patterns. It 
> has solutions
> 
> Answering your questions, you need to stablish baselines for 
> your software.
> Branches will have one baseline as their common start point, 
> as their "base". This base will usually be a stable version 
> of your software. Let's say your baseline is exactly your 
> current production release.

What you're saying is that the branches should be created as copies of trunk
at a specific revision, i.e. the production one. Have I understood
correctly?

> Sometimes your baseline will evolve. Maybe because your QA 
> team approved some new features for production, maybe because 
> you made urgent corrections.
> If it's approved for production it will be your new baseline. 
> All branches from this baseline will need to be "rebased" 
> before releasing, they need to incorporate any production changes.

So, basically, I need to merge changes in trunk from the previous
"production" revision to the current "production" revision (which may not be
HEAD at all) to the branches.

> Your correction will be tested isolated, approved and merged 
> to your trunk for tagging and release. If your development 
> branches are based on the trunk,

Re: unexpected mergeinfo results (v1.6.13)

2010-10-29 Thread Geoff Rowell

On Thu, Oct 28, 2010 at 4:40 PM, Wöster Benjamin  wrote:
> Hi all,
>
>
>
> I’m currently trying to clean up explicit mergeinfos that are scattered
> throughout our repository.
>
> Some of these explicit mergeinfos were created because people used sparse
> working copies and didn’t know about the impacts.
>
> So I’m trying to locate the pathes that contain non-inheritable mergeinfos,
> check that those merged revisions didn’t affect the children of that path,
>
> and redo the merge with the –record-only option for that path. This way, I
> hope I can eliminate the non-inheritable mergeinfos as first step of the
> cleanup.
>
>
>
> I’ve attached a perl script, that will reproduce a sample environment (it
> needs svn and svnadmin to be in your path).
>
> It creates (in your current working directory) a repository and a working
> copy. The script creates some test data, creates a feature branch,
>
> simulates some work (including cherry-picking from trunk to the feature
> branch) and at the end, it merges the branch back to the trunk.
>
> Last but not least, it creates a cleanup branch.
>
>
>
>
>
> This is the point where I am with my productive repository, and it turns
> out, that the cherry-picked revisions cause the behavior I wouldn’t have
> expected.
>
> The following is the session I use to reproduce the work till the point
> where I’m unsure if svn does things right.
>
>
>
> # creating the test data
>
> c:\mergeinfo>mergeinfo_fixture.pl
>
> c:\mergeinfo>dir
>
> Verzeichnis von c:\mergeinfo
>
>
>
> 28.10.2010  20:33      .
>
> 28.10.2010  20:33      ..
>
> 28.10.2010  20:28     2.108 mergeinfo_fixture.pl
>
> 28.10.2010  20:33      repo
>
> 28.10.2010  20:33      wc
>
>
>
> # navigate to the cleanup branch
>
> c:\mergeinfo>cd wc\branches\cleanup
>
>
>
> # checking for the non-inheritable merge info
>
> c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1
>
> /branches/feat_1/folder_1:2-6*
>
> /trunk/folder_1:4*
>
>
>
> So here it is. My understanding of the mergeinfo and the mergeinfo elision
> is, that once these revisions get merged into the children of that path,
>
> the explicit merge info should disappear. So I’m trying:
>
>
>
>
>
> (first with svn 1.6.12, which behaves the way I expected it to work)
>
>
>
> c:\mergeinfo\wc\branches\cleanup>svn –version
>
> svn, version 1.6.12 (r955767)
>
>
>
> c:\mergeinfo\wc\branches\cleanup>svn merge -r 3:4 --record-only
> "^/trunk/folder_1" folder_1
>
> c:\mergeinfo\wc\branches\cleanup>svn status
>
>  M  folder_1
>
>
>
> c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1
>
> /branches/feat_1/folder_1:2-6*
>
> /trunk/folder_1:4
>
>
>
> So we see: r4 is no longer been marked as non-inheritable, but since it
> still contains other non-inheritable mergeinfos,
>
> the data is still stored as explicit mergeinfo. I’m fine with that.
>
>
>
>
>
> (now the same with the newer svn 1.6.13)
>
>
>
> c:\mergeinfo\wc\branches\cleanup>svn revert . -R
>
> Reverted 'folder_1'
>
>
>
> c:\mergeinfo\wc\branches\cleanup>"c:\Program Files\Subversion\bin\svn.exe"
> --version
>
> svn, Version 1.6.13 (r1002816)
>
>
>
> c:\mergeinfo\wc\branches\cleanup>"c:\Program Files\Subversion\bin\svn.exe"
> merge -r 3:4 --record-only "^/trunk/folder_1" folder_1
>
> c:\mergeinfo\wc\branches\cleanup>svn status
>
>  M  folder_1\file_1
>
>  M  folder_1\file_2
>
>  M  folder_1\file_3
>
>
>
> c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1 -R
>
> folder_1\file_1 -
>
> folder_1 - /branches/feat_1/folder_1:2-6*
>
> /trunk/folder_1:4*
>
> folder_1\file_2 -
>
> folder_1\file_3 –
>
>
>
> Now, this is what I don’t understand. I merged (well, recorded) the changes
> of revision 4 into a fully recursive working copy.
>
> The result according to the new client is, that the revision was only merged
> down to folder_1, not into its children.
>
> Those instead get an explicit, empty mergeinfo property set, which means:
> “Nothing has been merged to me so far”.
>
>
>
> I’m unsure if this behavior is intended. It’s correct that none of the
> changes would have ever touched those files,
>
> but didn’t I tell svn to record that the revisions should be marked as
> merged? In my opinion, it simply refuses to do that (the 4* still exists),
>
> plus it adds more explicit mergeinfo to the childs (something I can’t
> understand right now, but maybe it makes sense).
>
>
>
> So what do you think? Is this behavior intended or did something go wrong
> between v1.6.12 and 1.6.13?
>
> Or maybe am I missing some important point?
>
>
>
> Thanks in advance!

The asterisk at the end of the revision number list indicates that the
revision list only applies to the current directory - i.e. it's
non-recursive.

BTW, I posted a similar Perl script to this mailing list some time ago.

When done, you may want to look into the Subversion Hook Framework for
a hook script that prevents recording merge into for lower level files
and folders.
-- 
Geoff Rowell
ge

Re: RES: Advice on process for web development

2010-10-29 Thread Les Mikesell


On 10/29/2010 12:10 PM, Luiz Guilherme Kimel wrote:

Let me try explain it better...

Let's say I just built the first version of an application, so I don't
currently have any branch, just the trunk where a small team of developers
were working until now. Our last build was tagged as 1.0.0.54 meaning it's
our 54 build of the 1.0 version. The QA team approved this build and it
becomes our first release of the software. Tag 1.0.0.54 is our baseline
which is equal to our trunk at that moment.

Now we have two new modules to develop in parallel. The team will receive
more people to speed up next releases, so we decided to start working with
branches. Two new branches are created: /branches/1.1a and /branches/1.1b.
Trunk is locked. Only reading is allowed. Developers are allowed to write
only on branches.


What do you gain by making 2 branches instead of continuing one line of 
development on the trunk and the one that would be disruptive to it on a 
branch?


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

svn export bug in 1.6.13

2010-10-29 Thread Chris Seawood

Hi,

I just ran across a bug in the 1.6.13 release.

Historically, 'svn export $SVNROOT/$PATH .' has just exported the
contents of $PATH into the current directory.  Under 1.6.13, the client
creates a subdir named after the last directory component of $PATH and
puts the contents there.  This change in behavior breaks some of our
release scripts and we've been forced to downgrade to 1.6.12.

# 1.6.13
[cseaw...@localhost foo]$ svn export --force $SVNROOT/trunk -N .
Atrunk
Atrunk/top.mk
Exported revision 50141.

# Replace 1.6.13 rpm with 1.6.12
[cseaw...@localhost foo]$ svn export --force $SVNROOT/trunk -N .
A.
Atop.mk
Exported revision 50141.

- cls

Re: svn export bug in 1.6.13

http://subversion.tigris.org/issues/show_bug.cgi?id=3727

Chris Seawood wrote on Fri, Oct 29, 2010 at 10:04:17 -0700:
> Hi,
> 
> I just ran across a bug in the 1.6.13 release.
> 
> Historically, 'svn export $SVNROOT/$PATH .' has just exported the
> contents of $PATH into the current directory.  Under 1.6.13, the client
> creates a subdir named after the last directory component of $PATH and
> puts the contents there.  This change in behavior breaks some of our
> release scripts and we've been forced to downgrade to 1.6.12.
> 
> # 1.6.13
> [cseaw...@localhost foo]$ svn export --force $SVNROOT/trunk -N .
> Atrunk
> Atrunk/top.mk
> Exported revision 50141.
> 
> # Replace 1.6.13 rpm with 1.6.12
> [cseaw...@localhost foo]$ svn export --force $SVNROOT/trunk -N .
> A.
> Atop.mk
> Exported revision 50141.
> 
> - cls

RES: RES: Advice on process for web development

Nothing if you don't have concurrent "new features" development lines. If
you can predict serial updates, then you won't need to branch. It's the
first option, it's less complex: one mainline of development, branching only
for emergency corrections from production tags.

But, if you have concurrent development efforts that can be stopped, change
in priority, take long time to be validated by a client etc, then I think
branching for feature and updating the trunk only with stable code that
needs to be spread turns everything easier and cleaner.

If you have many different clients for a single product, it may gets hard to
know which new feature will be released first. Clients will not always obey
to plans and clients may change their mind in what is priority and what is
not.

-Mensagem original-
De: Les Mikesell [mailto:lesmikes...@gmail.com] 
Enviada em: sexta-feira, 29 de outubro de 2010 14:00
Para: users@subversion.apache.org
Assunto: Re: RES: Advice on process for web development

On 10/29/2010 12:10 PM, Luiz Guilherme Kimel wrote:
> Let me try explain it better...
>
> Let's say I just built the first version of an application, so I don't
> currently have any branch, just the trunk where a small team of developers
> were working until now. Our last build was tagged as 1.0.0.54 meaning it's
> our 54 build of the 1.0 version. The QA team approved this build and it
> becomes our first release of the software. Tag 1.0.0.54 is our baseline
> which is equal to our trunk at that moment.
>
> Now we have two new modules to develop in parallel. The team will receive
> more people to speed up next releases, so we decided to start working with
> branches. Two new branches are created: /branches/1.1a and /branches/1.1b.
> Trunk is locked. Only reading is allowed. Developers are allowed to write
> only on branches.

What do you gain by making 2 branches instead of continuing one line of 
development on the trunk and the one that would be disruptive to it on a 
branch?

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

RE: Moving to Subversion for PL-SQL development

2010-10-29 Thread Dieter Oberkofler

Giulio,

I'm not sure if I correctly understood all the details of your questions but
I have been using Subversion in an environment that mostly consists of
C/C++, Java and an Oracle Database for quite some time and would be happy to
share my experience.

>From my general perspective managing PL/SQL in a version control system is
quite the same as managing any other sources.

The real complex thing is how to manage and upgrade the different
revisions/version of the database structure itself.
In our environment each "shippable" (alpha, beta, production) version of our
database structure (including PL/SQL) is tagged in Subversion.
The tag contains a snapshot of the scripts (SQL and PL/SQL) needed to create
a new database and additionally contains the appropriate update scripts
(typically a set of SQL Scripts executed in SQL*Plus) needed to update the
last revision to this one.
For an update we then use a custom developed application that determines the
source revision of the database and to witch revision to update, extracts
all the needed tags and executes the appropriate update scripts in each
tagged revision in the proper order.

I hope this helps a little.

Cheers,
Dieter


> -Original Message-
> From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com]
> Sent: Friday, October 29, 2010 15:11
> To: users@subversion.apache.org
> Subject: Moving to Subversion for PL-SQL development
> 
> First of all let me tell you that I don't know much of how PL-SQL
> development works so I might say something really obvious to you or
> more likely just wrong. Please forgive me.
> 
> I have a team that uses StarTeam as their VCS and we are now working on
> moving the project to Subversion. We are planning to use an importer
> for the initial load of the repository which seems to do what they want
> (I'm not looking after that part).
> 
> I have a problem though with their releasing process.
> 
> As I understand it, a major release is formed by all the packages and
> scripts, plus some table initialisation and sometime some data (I
> presume for defaults and stuff like that). Minor releases are done with
> patches which included only the packages that have changed from the
> previous patch.
> 
> So, if I want 5.4.0 (major release), I get everything. I unpack the
> kit, install it, run it, whatever it take and I'm done. If I am already
> on 5.4.0 and I want 5.4.3 (a minor release) I will be sent 3 patches:
> to 5.4.1, then 5.4.2 and finally 5.4.3. Apparently I just need to unzip
> them and I'm done.
> 
> Now, I might not be clear in the above process, so if someone with more
> experience with PL-SQL development and release wants to correct me,
> please do. I know there isn't one way to do things, but it's more
> likely that I understood wrong than we are doing it in a special way.
> 
> Anyway, if I am right, I'm struggling to come up with a process using
> Subversion. It seems they do not want to tag everything in trunk
> because that would be like a major release (apparently it would include
> those table and data things). Maybe we could re-organised the code to
> separate the packages from the data and then we could tag the packages,
> which is more what they want. And this way, to go to 5.4.3 I won't need
> 5.4.1 and 5.4.2 at all, which in my opinion is even better.
> 
> In the end what I am looking for with this email is some advice on how
> to proceed from people with more experience than me in projects using
> PL-SQL.
> 
> Thanks
> Giulio Troccoli
> 
> 
> Linedata Limited
> Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in
> England and Wales No 3475006 VAT Reg No 710 3140 03
> 
>

Re: Moving to Subversion for PL-SQL development

2010-10-29 Thread Les Mikesell


On 10/29/2010 1:06 PM, Dieter Oberkofler wrote:

Giulio,

I'm not sure if I correctly understood all the details of your questions but
I have been using Subversion in an environment that mostly consists of
C/C++, Java and an Oracle Database for quite some time and would be happy to
share my experience.

 From my general perspective managing PL/SQL in a version control system is
quite the same as managing any other sources.

The real complex thing is how to manage and upgrade the different
revisions/version of the database structure itself.
In our environment each "shippable" (alpha, beta, production) version of our
database structure (including PL/SQL) is tagged in Subversion.
The tag contains a snapshot of the scripts (SQL and PL/SQL) needed to create
a new database and additionally contains the appropriate update scripts
(typically a set of SQL Scripts executed in SQL*Plus) needed to update the
last revision to this one.
For an update we then use a custom developed application that determines the
source revision of the database and to witch revision to update, extracts
all the needed tags and executes the appropriate update scripts in each
tagged revision in the proper order.



There's something called liquibase (http://www.liquibase.org) that is 
supposed to manage this for you.  I don't know much about it other than 
that it is used by the OpenNMS project and run as an update step to fix 
schema changes between versions.


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

RES: Moving to Subversion for PL-SQL development

Dieter,

"For an update we then use a custom developed application that determines
the source revision of the database and to witch revision to update,
extracts all the needed tags and executes the appropriate update scripts in
each tagged revision in the proper order"

Sounds perfect! But how do you manage daily work on Oracle packages? Does
your developers work in local Oracle instances or a shared development
Oracle instance? Does your PL/SQL development tool integrates to SVN in some
way?

Could you describe it briefly? I'm interested in how you manage it. 

Thank you!


-Mensagem original-
De: Dieter Oberkofler [mailto:doberkofler.li...@gmail.com] 
Enviada em: sexta-feira, 29 de outubro de 2010 15:07
Para: 'Giulio Troccoli'
Cc: users@subversion.apache.org
Assunto: RE: Moving to Subversion for PL-SQL development

Giulio,

I'm not sure if I correctly understood all the details of your questions but
I have been using Subversion in an environment that mostly consists of
C/C++, Java and an Oracle Database for quite some time and would be happy to
share my experience.

>From my general perspective managing PL/SQL in a version control system is
quite the same as managing any other sources.

The real complex thing is how to manage and upgrade the different
revisions/version of the database structure itself.
In our environment each "shippable" (alpha, beta, production) version of our
database structure (including PL/SQL) is tagged in Subversion.
The tag contains a snapshot of the scripts (SQL and PL/SQL) needed to create
a new database and additionally contains the appropriate update scripts
(typically a set of SQL Scripts executed in SQL*Plus) needed to update the
last revision to this one.
For an update we then use a custom developed application that determines the
source revision of the database and to witch revision to update, extracts
all the needed tags and executes the appropriate update scripts in each
tagged revision in the proper order.

I hope this helps a little.

Cheers,
Dieter


> -Original Message-
> From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com]
> Sent: Friday, October 29, 2010 15:11
> To: users@subversion.apache.org
> Subject: Moving to Subversion for PL-SQL development
> 
> First of all let me tell you that I don't know much of how PL-SQL
> development works so I might say something really obvious to you or
> more likely just wrong. Please forgive me.
> 
> I have a team that uses StarTeam as their VCS and we are now working on
> moving the project to Subversion. We are planning to use an importer
> for the initial load of the repository which seems to do what they want
> (I'm not looking after that part).
> 
> I have a problem though with their releasing process.
> 
> As I understand it, a major release is formed by all the packages and
> scripts, plus some table initialisation and sometime some data (I
> presume for defaults and stuff like that). Minor releases are done with
> patches which included only the packages that have changed from the
> previous patch.
> 
> So, if I want 5.4.0 (major release), I get everything. I unpack the
> kit, install it, run it, whatever it take and I'm done. If I am already
> on 5.4.0 and I want 5.4.3 (a minor release) I will be sent 3 patches:
> to 5.4.1, then 5.4.2 and finally 5.4.3. Apparently I just need to unzip
> them and I'm done.
> 
> Now, I might not be clear in the above process, so if someone with more
> experience with PL-SQL development and release wants to correct me,
> please do. I know there isn't one way to do things, but it's more
> likely that I understood wrong than we are doing it in a special way.
> 
> Anyway, if I am right, I'm struggling to come up with a process using
> Subversion. It seems they do not want to tag everything in trunk
> because that would be like a major release (apparently it would include
> those table and data things). Maybe we could re-organised the code to
> separate the packages from the data and then we could tag the packages,
> which is more what they want. And this way, to go to 5.4.3 I won't need
> 5.4.1 and 5.4.2 at all, which in my opinion is even better.
> 
> In the end what I am looking for with this email is some advice on how
> to proceed from people with more experience than me in projects using
> PL-SQL.
> 
> Thanks
> Giulio Troccoli
> 
> 
> Linedata Limited
> Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in
> England and Wales No 3475006 VAT Reg No 710 3140 03
> 
>

RES: Moving to Subversion for PL-SQL development

Wow! This sounds really very good. I will try it here!

PS: OpenNMS also looks a very nice finding.

Thank you! (twice)

-Mensagem original-
De: Les Mikesell [mailto:lesmikes...@gmail.com] 
Enviada em: sexta-feira, 29 de outubro de 2010 15:19
Para: users@subversion.apache.org
Assunto: Re: Moving to Subversion for PL-SQL development

There's something called liquibase (http://www.liquibase.org) that is 
supposed to manage this for you.  I don't know much about it other than 
that it is used by the OpenNMS project and run as an update step to fix 
schema changes between versions.

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

RE: Moving to Subversion for PL-SQL development

2010-10-29 Thread Dieter Oberkofler

Luiz,

> Sounds perfect! But how do you manage daily work on Oracle packages?
> Does your developers work in local Oracle instances or a shared
> development Oracle instance? 

There is no simple answer to this and it really depends on how "different" a
database version gets.
I'm not sure, if I'm able to describe this but let me try:
Typically every developer has its local Database Instance that in our case
are schemas on a single server and there is a master schema that always hold
a "consistent snapshot" and most often is the same as the tagged revision.
If there are major changes that may be needed or affect other developers in
the team, there is a branch that hold the individual changes and the changes
will be merged into the main trunk when they should be made available to
others.
Our update application has a special "development" update option that
instead of moving from one tagged revision to the next one also allows to
"just" run a set of update scripts currently available in the trunk of our
database repository and this would then allow the team members to eventually
(if needed) upgrade their local database to some "intermediate" revision.

> Does your PL/SQL development tool integrates to SVN in some way?
We mostly use a simple editor (or PlEdit) to edit SQL and PL/SQL scripts and
then run all our scripts with good old SQL*Plus, so there is no SVN
integration.
We have spend quite some time to figure out how to integrate some kind of
locking mechanism in our toolset but at the end found out that there is
little out there and we do not really need it as much as we originally would
have expected. There is a lot less conflicts that we anticipated because the
database design is (at least in our organization) a rather centralized type
of work.
We generally do not use any tools that integrate SVN because we very much
like using the SVN command line or TortoiseSVN.

Cheers,
Dieter


> -Original Message-
> From: Luiz Guilherme Kimel [mailto:lki...@dba.com.br]
> Sent: Friday, October 29, 2010 21:25
> To: users@subversion.apache.org
> Subject: RES: Moving to Subversion for PL-SQL development
> 
> Dieter,
> 
> "For an update we then use a custom developed application that
> determines the source revision of the database and to witch revision to
> update, extracts all the needed tags and executes the appropriate
> update scripts in each tagged revision in the proper order"
> 
> Sounds perfect! But how do you manage daily work on Oracle packages?
> Does your developers work in local Oracle instances or a shared
> development Oracle instance? Does your PL/SQL development tool
> integrates to SVN in some way?
> 
> Could you describe it briefly? I'm interested in how you manage it.
> 
> Thank you!
> 
> 
> -Mensagem original-
> De: Dieter Oberkofler [mailto:doberkofler.li...@gmail.com]
> Enviada em: sexta-feira, 29 de outubro de 2010 15:07
> Para: 'Giulio Troccoli'
> Cc: users@subversion.apache.org
> Assunto: RE: Moving to Subversion for PL-SQL development
> 
> Giulio,
> 
> I'm not sure if I correctly understood all the details of your
> questions but I have been using Subversion in an environment that
> mostly consists of C/C++, Java and an Oracle Database for quite some
> time and would be happy to share my experience.
> 
> From my general perspective managing PL/SQL in a version control system
> is quite the same as managing any other sources.
> 
> The real complex thing is how to manage and upgrade the different
> revisions/version of the database structure itself.
> In our environment each "shippable" (alpha, beta, production) version
> of our database structure (including PL/SQL) is tagged in Subversion.
> The tag contains a snapshot of the scripts (SQL and PL/SQL) needed to
> create a new database and additionally contains the appropriate update
> scripts (typically a set of SQL Scripts executed in SQL*Plus) needed to
> update the last revision to this one.
> For an update we then use a custom developed application that
> determines the source revision of the database and to witch revision to
> update, extracts all the needed tags and executes the appropriate
> update scripts in each tagged revision in the proper order.
> 
> I hope this helps a little.
> 
> Cheers,
> Dieter
> 
> 
> > -Original Message-
> > From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com]
> > Sent: Friday, October 29, 2010 15:11
> > To: users@subversion.apache.org
> > Subject: Moving to Subversion for PL-SQL development
> >
> > First of all let me tell you that I don't know much of how PL-SQL
> > development works so I might say something really obvious to you or
> > more likely just wrong. Please forgive me.
> >
> > I have a team that uses StarTeam as their VCS and we are now working
> > on moving the project to Subversion. We are planning to use an
> > importer for the initial load of the repository which seems to do
> what
> > they want (I'm not looking after that part).
> >
> > I have a problem thoug

Observed changes didn't match count

2010-10-29 Thread Ryan Schmidt

The Pure project is trying to switch from Subversion to Mercurial, and are 
having trouble with svnsync.

http://groups.google.com/group/pure-lang/msg/bf588ebe14d6fb14

On revision 2967, it gives the message "Observed changes didn't match count", 
and I get the same message when just doing an "svn log -v" on that revision:

$ svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk
svn: Observed changes didn't match count
$

"svn log" without "-v" works fine, as does "svn diff".

Google searching for this error message yields only one other occurrence, which 
was not really solved.

I'm unsure what we should try from here. Possibly this error is unique to 
Google Code's Subversion backend, but still I would have expected others to 
have run into it. Any suggestions?

Re: Observed changes didn't match count

Short version: it's a bug in Google's backend, and I can reproduce it
with neon but not with serf.

(more below)


Ryan Schmidt wrote on Fri, Oct 29, 2010 at 16:24:20 -0500:
> The Pure project is trying to switch from Subversion to Mercurial, and are 
> having trouble with svnsync.
> 
> http://groups.google.com/group/pure-lang/msg/bf588ebe14d6fb14
> 
> On revision 2967, it gives the message "Observed changes didn't match count", 
> and I get the same message when just doing an "svn log -v" on that revision:
> 
> $ svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk
> svn: Observed changes didn't match count

[[[
% $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk --config-option 
servers:global:http-library=serf

% echo $?
0
% $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk --config-option 
servers:global:http-library=neon
...
subversion/libsvn_ra_neon/util.c:773: (apr_err=160004)
svn: Observed changes didn't match count
% echo %?
1
% ./tools/dev/which-error.py 160004
00160004  SVN_ERR_FS_CORRUPT
% $svn --version | head -n2
svn, version 1.7.0 (dev build)
   compiled Oct 27 2010, 15:38:01
% 
]]]

> $
> 
> "svn log" without "-v" works fine, as does "svn diff".
> 
> Google searching for this error message yields only one other occurrence, 
> which was not really solved.
> 
> I'm unsure what we should try from here. Possibly this error is unique
> to Google Code's Subversion backend,

The error code confirms your suspicion.  Furthermore, the word
"Observed" doesn't appear in Subversion's source code.

> but still I would have expected
> others to have run into it. Any suggestions?
> 
> 
>

Re: Observed changes didn't match count

2010-10-29 Thread Ryan Schmidt

On Oct 29, 2010, at 17:11, Daniel Shahaf wrote:

> Short version: it's a bug in Google's backend, and I can reproduce it
> with neon but not with serf.

> % $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk 
> --config-option servers:global:http-library=serf
> 
> % echo $?
> 0
> % $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk 
> --config-option servers:global:http-library=neon
> ...
> subversion/libsvn_ra_neon/util.c:773: (apr_err=160004)
> svn: Observed changes didn't match count
> % echo %?
> 1
> % ./tools/dev/which-error.py 160004
> 00160004  SVN_ERR_FS_CORRUPT
> % $svn --version | head -n2
> svn, version 1.7.0 (dev build)
>   compiled Oct 27 2010, 15:38:01
> % 

I agree using serf instead of neon makes the error message go away. But it also 
doesn't actually show the list of files affected by the commit like it should. 
See "svn diff --summarize -r2967" for all the files that should be shown there.

Also, even when I change http-library to serf in the servers config file, 
svnsync still shows the "Observed changes didn't match count" error. Does 
svnsync not use this library setting?

>> I'm unsure what we should try from here. Possibly this error is unique
>> to Google Code's Subversion backend,
> 
> The error code confirms your suspicion.  Furthermore, the word
> "Observed" doesn't appear in Subversion's source code.

I suppose we should report the problem to Google Code and hope they can 
uncorrupt the repository somehow? Apparently a couple dozen subsequent 
revisions see the same error, through r2993.

Re: Observed changes didn't match count