Re: commit failed - No such file or directory

[Vikrama Sanjeeva]

Hi All,

  Someone please help me to troubleshoot this issue.

Thanks.

Bye,
Viki.

On Mon, May 10, 2010 at 3:42 PM, Vikrama Sanjeeva
wrote:

> Hi,
>
> 1: Did backup of live repository as below:
> hot-backup.py --archive-type=zip /my/svn/repo /my/svn/backup
>
> 2: Unzipped /my/svn/backup/repo-7.zip
>
> 3: checkout /my/svn/backup/repo-7  (using Tortoise)
>
> 4: On commit, am getting below error in Apache error_log
> ###
>  Can't create directory /my/svn/backup/repo-7/db/transactions/7-8.txn': No
> such file or directory  [500, #2]
> ###
>
> *httpd.conf*:
>  
>   DAV svn
>  SVNPath /my/svn/backup/repo-7
>   AuthType Basic
>   AuthName "Subversion repository"
>   AuthUserFile /my/svn/users/svn-repo-auth-file
>   Require valid-user
> 
>
> Please guide.
>
> Bye,
> Viki.
>

RE: commit failed - No such file or directory

[Cooke, Mark]

> On Mon, May 10, 2010 at 3:42 PM, Vikrama Sanjeeva 
>  wrote:
> 
>   Hi,
>   
>   1: Did backup of live repository as below:
>   hot-backup.py --archive-type=zip /my/svn/repo /my/svn/backup
>   
>   2: Unzipped /my/svn/backup/repo-7.zip
>   
>   3: checkout /my/svn/backup/repo-7  (using Tortoise)
>   
>   4: On commit, am getting below error in Apache error_log
>   ###
>Can't create directory 
> /my/svn/backup/repo-7/db/transactions/7-8.txn': No such file 
> or directory  [500, #2]
>   ###
>   
>   httpd.conf:
>
> DAV svn
>SVNPath /my/svn/backup/repo-7
> AuthType Basic
> AuthName "Subversion repository"
> AuthUserFile /my/svn/users/svn-repo-auth-file
> Require valid-user
>   
>   
>   Please guide.
>   
>   Bye,
>   Viki.
>   
> 
>   Someone please help me to troubleshoot this issue.
> 
> Thanks.
> 
> Bye,
> Viki.
> 
Hmm, you do not give any information as to what platform(s) and versions
of tortoise / subversion you are using.  Your paths look unix but
tortoise is windoze so I assume you have a linux server of some flavour
running subversion behind apache.  I assume you did your backup /
restore on the server then accessed the repo from a windoze client.

As a first stab in the dark: have you checked / set the proper
permissions for the apache user on the new directories
(/my/svn/backup/repo-7)?  Are all the required directories (as created
by svnadmin when you create a new repo) there?  I'm not sure what
hot-backup does as I've never used it, does it backup the extra
directories?

~ mark c

Re: commit failed - No such file or directory

[Vikrama Sanjeeva]

Hi,

Subversion 1.6.9 hosted on Solaris 5.10 and am using TortoiseSVN 1.6.7 on
WinXP Pro SP2

permissions on "/my/svn/backup/repo-7" is "chmod -R 777"  [so it should be
accessible by apache and all]

/my/svn/repo> ls
README.txt  confdav db  format  hooks
locks

/my/svn/backup/repo-7> ls
README.txt  confdb  format  hooks   locks

Only "dav" folder is missing in backup taken by "hot-backup.py"

size of "/my/svn/repo" 89K
size of "/my/svn/backup/repo-7" 81K

Bye,
Viki.

On Tue, May 11, 2010 at 10:59 AM, Cooke, Mark wrote:

> > On Mon, May 10, 2010 at 3:42 PM, Vikrama Sanjeeva
> >  wrote:
> >
> >   Hi,
> >
> >   1: Did backup of live repository as below:
> >   hot-backup.py --archive-type=zip /my/svn/repo /my/svn/backup
> >
> >   2: Unzipped /my/svn/backup/repo-7.zip
> >
> >   3: checkout /my/svn/backup/repo-7  (using Tortoise)
> >
> >   4: On commit, am getting below error in Apache error_log
> >   ###
> >Can't create directory
> > /my/svn/backup/repo-7/db/transactions/7-8.txn': No such file
> > or directory  [500, #2]
> >   ###
> >
> >   httpd.conf:
> >
> > DAV svn
> >SVNPath /my/svn/backup/repo-7
> > AuthType Basic
> > AuthName "Subversion repository"
> > AuthUserFile /my/svn/users/svn-repo-auth-file
> > Require valid-user
> >   
> >
> >   Please guide.
> >
> >   Bye,
> >   Viki.
> >
> >
> >   Someone please help me to troubleshoot this issue.
> >
> > Thanks.
> >
> > Bye,
> > Viki.
> >
> Hmm, you do not give any information as to what platform(s) and versions
> of tortoise / subversion you are using.  Your paths look unix but
> tortoise is windoze so I assume you have a linux server of some flavour
> running subversion behind apache.  I assume you did your backup /
> restore on the server then accessed the repo from a windoze client.
>
> As a first stab in the dark: have you checked / set the proper
> permissions for the apache user on the new directories
> (/my/svn/backup/repo-7)?  Are all the required directories (as created
> by svnadmin when you create a new repo) there?  I'm not sure what
> hot-backup does as I've never used it, does it backup the extra
> directories?
>
> ~ mark c
>

Re: mimimal backup of working copies?

[Tino Schwarze]

On Wed, May 05, 2010 at 11:38:51AM -0500, Les Mikesell wrote:
> Does anyone know of a way to backup/move/copy checked out working copies  
> such that you can skip all the parts that 'svn update' would  
> reconstruct?  I'm about to copy the home directories of a machine used  
> mostly for checkout/build/test operations to a remote location and it  
> occurred to me that most of what I'll be copying is unnecessary but I  
> don't want to disrupt the directory structure or hooks to the 
> repositories.

I'd rather not try that trick - you will spoil the "I did not update
that working copy since I need it at exactly this stage" use case - I'd
be upset as an developer if my files vanished because of some clever
admin. (And I'm admin as well, so I understand your desire not to copy
redundant files.)

Tino.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."

www.lichtkreis-chemnitz.de
www.tisc.de

Re: Performance Tips?

[Tino Schwarze]

Hi Brendan,

On Wed, May 05, 2010 at 09:21:43AM -0400, Brendan Farr-Gaynor wrote:

> I run a small team of web developers (6) who all work from an in-house
> repository. We make lots of commits and often and notice the
> performance gets pretty bad. Sometimes taking as long as 2 minutes to
> commit a change. We rely a lot on server-side software so we often
> need to commit to see what our code will do, this can get painful
> during a debug process where as a developer you'll often want to
> commit many little changes quickly within the span of 5-10 minutes.

I'd rather not commit during debugging, but setup local development
environments for the developers so they can work out issues locally,
then commit a supposed-to-work version which gets further testinggq.
You're really bloating the repository that way (and won't have a useful
commit history since most log messages will be empty or "try this" or
"..." or whatever).

> We're using SVN on a newer quad-core xServe with about 4GB of ram and
> a standard 7200 RPM disk (eSATA). Is there something we can do on the
> hardware side that would help? Solid State drive? More RAM? Is there
> something in our SVN config that I should be playing with? We're
> currently using the stock install and config that Apple ships with OS
> X Server 10.6 (Snow Leopard). 

I would not put data on a single disk on any server. It should be at
least a RAID-1, especially if you rely so heavily on the repository
being available.

HTH,

Tino.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."

www.lichtkreis-chemnitz.de
www.tisc.de

Re: Performance Tips?

[Tino Schwarze]

Hi Brendan,

On Wed, May 05, 2010 at 09:46:10AM -0400, Brendan Farr-Gaynor wrote:

> Thanks for your response! Running local copies of the environment
> doesn't seem practical in this case, my guys are working on 10+
> projects at a time all of which can be in different states and which
> need many different modules in place via apache and php which would
> take forever to setup and even support across multiple workstations.

Well, that's exactly what SVN is very useful for - just check in apache
configs as part of the project, each config nicely contained in a
pre-configured , like this:

Listen 127.0.0.1:8001


  ServerName Project1
  ...


Then the next project has
Listen 127.0.0.1:8002


  ServerName Project2
  ...


> Not having to worry about client machine consistency keeps things sane
> (in my opinion). When the commits are fast, the central model works
> well, I'm just trying to figure out a way to keep them fast.

To me it feels like getting along a little longer before things finally
break for one reason or another.
Sooner or later you'll have to switch anyway.

HTH,

Tino.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."

www.lichtkreis-chemnitz.de
www.tisc.de

Re: How do I determine if svn:mergeinfo is corrupt and how would I fix it.

[Stein Somers]

I suspect I have corrupt mergeinffo but I'm not sure. Does anyone know
how I'd make a determination and what resources are out there to help
fix problems?


I'd make the determination by reading and understanding the mergeinfo 
values. They are plain text after all. The resource to read is


http://www.collab.net/community/subversion/articles/merge-info.html

Personally I think you need a file-level merge module that is tailored 
to the programming language used, or a well thought out protocol to have 
line-based merging sort out things for you and very disciplined programmers.


--
Stein

Re: Cannot reintegrate feature branch

[Stefan Sperling]

On Tue, May 11, 2010 at 12:06:50PM +0800, Jean Seurin wrote:
> Hi Stefan
> 
> first of all thanks for spending the time for this long thorough analysis.
> 
> 1) I want to state that we're using a range of different SVN
> clients, cli, Intellij Eclipse, mainly, and some people under
> Windows may use Tortoise - bu those usually don't venture into
> merges - yet.
> I tought at first it could be the cause of the problem, since I have
> had bad experiences with SVN clients on some IDEs.
> But after reading through your whole analysis, I think I get where
> the problem comes from. Here's our setup right now:
> 
>[copy]   [merge of bugfix r4 only]
>   release-branch-1.13--r2---r4--
> /\
> trunk   ---r1r3--r6--
>   \\  \   / [--reintegrate not 
> possible anymore]
> feature-branch-dev-r5--r7-
> [copy]   [merge]   [merge]
> 
> Hope the drawing make sense: we have to merge back bug fix from
> /release branch/ back to trunk. We don't really have to use merge
> command for that, but some developer start to take a fancy into it
> and uses it to merge a revision only, that corresponds to a bug fix.

Can you state which revisions were merged where in your example?
I guess r2 is the commit which was not merged back into trunk?
How was the merge from release-branch-1.13 to trunk in r6 done?

If you want all changes that happened in the release branch
merged to trunk, you can use --reintegrate for that, since the merge 
is going into the opposite direction to the branch copy.
But there's a catch: if you want to reintegrate multiple times (to merge
more bufixes later), you have to use the trick described here:
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice

Or you can do a cherry picking merge (grab one or more revisions
like your developer did). But cherry picking should only be done
into a single direction (mostly to keep things simple and prevent
developer insanity, but also because it makes merging with svn easier).
So if you ever cherry-picked one way, do not cherry pick the other way.

The canonical way to do the cherry-pick would be:
 cd trunk-working-copy
 svn merge -c 6 ^/release-branch-1.13
 
> If I follow you - and that would make sense - once this merge to
> trunk makes its way to the /feature branch/, this one becomes not
> 'reintegratable' anymore.

It depends. I'm still not entirely sure I understand your example.
If you could describe how each of the merges was (reintegrate merge,
sync merge, cherry-pick merge) that would help.

> This use case appears to be quite regular to me. If it is not
> possible to use it, it'd be better to know it before using /Feature
> branch.

It is possible to use features branches and release branches at
the same time. Merging bug fixes from the release branch to the
trunk should not prevent reintegration of the feature branch.
That alone does not explain the problem.

I still think it's more likely that your problem is due to the
scattered subtree mergeinfo on trunk and possible the project-dev
branch. The mergeinfo shows "holes" in the merge history between
project-dev and trunk. These holes need to be filled before project-dev
is ready for reintegration.

I don't think a single cherry-picking merge from an unrelated branch
would cause this problem.

> /2) How can I solve my problem?
> It seems from the reasoning above that the right solution would be
> to do a complete merge of the Release branch 1.13 to the trunk -
> instead of just a revision. I doubt that is possible for us.
> If not, what are the options left? /

Making sure merges into your project-dev branch from trunk cover
a continuous revision range is your best option I think.

> /I want to get rid of the subtree mergeinfo - for those blocking
> files, they seem to have been commited by mistake anyway- to keep
> only the trunk root mergeinfo. Can I delete them manually?
> If not how to get rid of subtree mergeinfo?

In general, do not delete mergeinfo yourself.
In some cases, where mergeinfo was created by accident (seems to be
the case in your situation), you can delete mergeinfo if and only if
there exists mergeinfo above it which is inheritable (does not have a *)
and is a superset of the mergeinfo below it.

E.g. this subtree mergeinfo is safe to delete:

 trunk [svn:mergeinfo = branch1:r4-50, branch2:r30]
   src
foo.c  [svn:mergeinfo = branch1:r10-25, branch2:r30] <- subtree mergeinfo

But this isn't safe to delete:

 trunk [svn:mergeinfo = branch1:r4-50]
   src
foo.c  [svn:mergeinfo = branch1:r10-25, branch2:r30] <- subtree mergeinfo

and this also isn't safe to delete:

 trunk [svn:mergeinfo = branch1:r4-50*, branch2:r30*]
   src
foo.c  [svn:mergeinfo = branch1:r10-25, branch2:r30] <- subtree mergeinfo

Have you tried the merges from trunk to the pro

Re: How do I determine if svn:mergeinfo is corrupt and how would I fix it.

[Julian Foad]

Hi Peter.

The mergeinfo "corruption" may be real, but just as likely it doesn't
work the way you expect, or Subversion is being asked to perform
combinations of merging that it doesn't support automatically.  It seems
likely that even if there is some "corrupt" merge info, that is only a
part of the problem.  It sounds like you might benefit from
understanding better how Subversion's merging works "on the inside"
which will give you the rationale for what it can and can't do "on the
outside".

If that's the case, have a look right at the end of this article
 at
the list of "Parting Thoughts" which says how to stick to the kinds of
merging that Subversion can cope with.  (That article is mostly the
intricate detail of svn:mergeinfo which you really don't want to know.)
Also, WANdisco has an upcoming free training webinar on "Branching and
Merging" which could be useful if you can wait till July 14:
.

As for the specific issues you mention, I can't comment much without
seeing the precise detail.  It would be a good idea to raise each one as
a separate query, giving a full transcript of input and output and what
you think is wrong.

Regards,
- Julian


> I suspect I have corrupt mergeinffo but I'm not sure. Does anyone know
> how I'd make a determination and what resources are out there to help
> fix problems? 
> 
> Here’s the issue. My team recently moved to agile and uses feature
> branches (story branches really) where different teams work on the
> same sources concurrently. As the story achieves a high state of
> readiness the team merges to trunk. The merges are taking days or
> weeks due to missing changes, unexpected changes, and conflicts. We
> are talking about teams of 5-10 people and the effort/churn seems way
> to high.
> 
> People use the this merge pattern 
> 
> a) PULL - merge trunk-to-branch, resolve, test, commit 
> 
> b) PUSH - merge branch-to-trunk, resolve, test, commit 
> 
> c) Recreate branch (or usually create new story branch and drop old
> since it's done)
> 
> By the end of this the branch and trunk should be in alignment.
> 
> Problems we are seeing:
> 
>  1. changes not reported during trunk-to-branch merge show up in
> subsequent branch-to-trunk 
>  2. conflicts on svn:mergefinfo properties during merge 
>  3. file missing, but local edit on new file added in branch and
> pushed to trunk 
>  4. incoming + local delete (file deleted on trunk and branch
> shows as conflict)
> 
> (1) Should not be happening. The pull from branch to trunk should put
> the two in sync for all changes already on trunk. The changes in
> branch-to-trunk merge are changes that happened on the trunk. So in
> the first merge they should have propagated to branch but didn’t. This
> points to corruption in mergeinfo data which would “hide” trunk
> changes.
> 
> (2) Should not be happening. SVN should be managing the changes in the
> merge tracking. This also points to corruption in the mergeinfo data
> 
> (3) Should not be happening. This is a case of a new file added on
> branch. It should show up as a new file added to trunk. This also
> points to corruption in the merge info data.
> 
> (4) I believe this is a SVN bug and that we can’t fix this. Still if
> this were our only problem I'd be happy
> 
> We are currently on svn 1.5.x server with clients using svn 1.6.x and
> svn+ssh for connecting. We plan to go up to the latest and greatest
> SVN since some fixes may impact our problems.
> 
> Still, it sure looks like our mergeinfo data is wrong. 
> 
>   * Merges that don't report all changes 
>   * Conflicts in merge of mergeinfo properites
> 
> Any good places for me to start looking?
> 
> 
> 
> FYI, I also posted this to Stackoverflow, but thus far "move to git"
> has been the only response and that's not really an option for me at
> present.
> 

Re: How do I determine if svn:mergeinfo is corrupt and how would I fix it.

[Stefan Sperling]

On Mon, May 10, 2010 at 12:12:49PM -0400, Peter Kahn wrote:
> People use the this merge pattern
> 
> a) PULL - merge trunk-to-branch, resolve, test, commit
> 
> b) PUSH - merge branch-to-trunk, resolve, test, commit
> 
> c) Recreate branch (or usually create new story branch and drop old since
> it's done)

PULL, PUSH, and Recreate branch could be anything.
Can you describe the exact commands (or button clicks) you are using at
each of these steps? Without that information it's pretty much impossible
to tell what the root of your problem might be.

Also, if you could provide your complete mergeinfo that would help:

  svn propget -R -v svn:mergeinfo $REPOS_URL > allmergeinfo.txt

Even if it's a lot of output, post all of it.
You can do search/replace operations on pathnames which are
confidential if you need to.

Thanks,
Stefan

Question regarding: * mergeinfo improvements with non-inheritable mergeinfo (issue #3573)

[Graf, Andreas]

Hi SVN folks!

 

According the bug-database the issue #3573 is only patching the static
function 'diff_mergeinfo_props' at props.c (and a python test script).

 

For me it seems that there is no need to update our server 1.6.6 to
1.6.11 because only the external functions 'svn_wc__merge_props' and
'svn_wc_merge_props3' are referencing the changed function and these (wc
merge) functions are only referenced by the client (/usr/bin/svn - via.
libsvn_wc-1.so). 

 

Is that right?

Or do we have to update the server too?

 

Best Regards,

Andreas Graf

 

 

 




..
Confidentiality Notice
The information contained in this Email, and any attachments, is intended for 
the named recipients only. It may contain confidential and/or legally 
privileged information. If you are not the intended recipient, you must not 
copy, store, distribute or take any action in reliance on it. Any views 
expressed do not necessarily reflect the views of the company.

If you receive this Email by mistake, please advise the sender by using the 
reply facility in your Email software and then delete it.
.

Re: Question regarding: * mergeinfo improvements with non-inheritable mergeinfo (issue #3573)

[Stefan Sperling]

On Tue, May 11, 2010 at 01:29:47PM +0200, Graf, Andreas wrote:
> Hi SVN folks!
> 
> According the bug-database the issue #3573 is only patching the static
> function 'diff_mergeinfo_props' at props.c (and a python test script).
> 
> For me it seems that there is no need to update our server 1.6.6 to
> 1.6.11 because only the external functions 'svn_wc__merge_props' and
> 'svn_wc_merge_props3' are referencing the changed function and these (wc
> merge) functions are only referenced by the client (/usr/bin/svn - via.
> libsvn_wc-1.so). 
> 
>  
> 
> Is that right?
> 
> Or do we have to update the server too?

If you're really only interested in a fix which happened in libsvn_wc,
updating the client is sufficient.

Updating both ends to 1.6.11 will give you all known problem fixes.
Before reporting a new problem please update both ends and reproduce
the problem.

Stefan

long path names on windows prefixed with \\?\ not handled by svn commands

[Heinz Prantner]

Hello,

running svn client commands other than svn checkout on windows fail,
if the path name (of the local working copy location) is prefixed  
with \\?\.

The prefix is required for path names longer than  255 or so.

It seems that svn commands like svn info or svn status behave different
than svn checkout command regarding the path name prefix.

example:

svn info \\?\c:\long\path\name
svn: '\' is not a working copy

Any thoughts?

(I am using svn client version 1.6.11 from CollabNet)

Thanks,
Heinz

AW: Question regarding: * mergeinfo improvements with non-inheritable mergeinfo (issue #3573)

[Graf, Andreas]

Thank you Stefan!
This was really fast...

Best regards,
Andreas Graf

-Ursprüngliche Nachricht-
Von: Stefan Sperling [mailto:s...@elego.de] 
Gesendet: Dienstag, 11. Mai 2010 14:01
An: Graf, Andreas
Cc: users@subversion.apache.org; Bruedern, Ivonne
Betreff: Re: Question regarding: * mergeinfo improvements with non-inheritable 
mergeinfo (issue #3573)

On Tue, May 11, 2010 at 01:29:47PM +0200, Graf, Andreas wrote:
> Hi SVN folks!
> 
> According the bug-database the issue #3573 is only patching the static
> function 'diff_mergeinfo_props' at props.c (and a python test script).
> 
> For me it seems that there is no need to update our server 1.6.6 to
> 1.6.11 because only the external functions 'svn_wc__merge_props' and
> 'svn_wc_merge_props3' are referencing the changed function and these (wc
> merge) functions are only referenced by the client (/usr/bin/svn - via.
> libsvn_wc-1.so). 
> 
>  
> 
> Is that right?
> 
> Or do we have to update the server too?

If you're really only interested in a fix which happened in libsvn_wc,
updating the client is sufficient.

Updating both ends to 1.6.11 will give you all known problem fixes.
Before reporting a new problem please update both ends and reproduce
the problem.

Stefan



..
Confidentiality Notice
The information contained in this Email, and any attachments, is intended for 
the named recipients only. It may contain confidential and/or legally 
privileged information. If you are not the intended recipient, you must not 
copy, store, distribute or take any action in reliance on it. Any views 
expressed do not necessarily reflect the views of the company.

If you receive this Email by mistake, please advise the sender by using the 
reply facility in your Email software and then delete it.
.

Re: mimimal backup of working copies?

[Les Mikesell]

Tino Schwarze wrote:

On Wed, May 05, 2010 at 11:38:51AM -0500, Les Mikesell wrote:
Does anyone know of a way to backup/move/copy checked out working copies  
such that you can skip all the parts that 'svn update' would  
reconstruct?  I'm about to copy the home directories of a machine used  
mostly for checkout/build/test operations to a remote location and it  
occurred to me that most of what I'll be copying is unnecessary but I  
don't want to disrupt the directory structure or hooks to the 
repositories.


I'd rather not try that trick - you will spoil the "I did not update
that working copy since I need it at exactly this stage" use case - I'd
be upset as an developer if my files vanished because of some clever
admin. (And I'm admin as well, so I understand your desire not to copy
redundant files.)


Just to put things in perspective here, it took two full nights to copy the home 
directories over a WAN to its new location when in fact everything except a few 
scripts and the top level directories could have been checked back out and 
didn't need to be copied at all.  As a developer, would you be happy about 
losing a couple of days of work for something that should have a better way to 
do?   I happen to use backuppc to back the system up so it at least de-dups the 
multiple identical copies across the workspaces and their .svn counterparts but 
it would be nicer if there were a way to explicitly avoid or even remove 
anything that could be regenerated.  Maybe this would involve creating a script 
to update to the current revision of each file in the workspace to get back to 
the identical state - and of course keeping any modified files.


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

Subversion with mod_dav_svn (WebDAV) and large (binary) files

[Marcus Scheller]

Dear SVN-Team,

is a subversion-server with 'mod_dav_svn module' (http/https)   able to handle 
large  (binary) files (> 2GB)?

Are there any server/ os limitations?
Are there client-limitations using a web-client  for checkin/checkout large 
files (>2GB)

I've heard that these browser has limits:

IE6: 2GB

IE7: 4GB

IE8: no limit

Firefox: 4GB


Is SVN affected by these limitations?

Maybe you can throw some light on this...

Many Thanks
Best Regards
Marcus Scheller
Germany









Marcus Scheller

Innoface GmbH

Amalienstr. 25

76133 Karlsruhe

Germany

http://www.innoface.de



Durchwahl:


 +49 (0)721 6268 741


Tel.:


 +49 (0)721 6268 730


Mobile:


 +49 (0)163 5666 321


Fax:


 +49 (0)721 6268 733




Gesch?ftsf?hrer: A. Dideban, M. Scheller, M. Miss, T. Fehrer, J. G?ntzel

Registriergericht: Mannheim HRB 109662

Ust-IdNr.: DE 813309902

Best practice for moving folders around?

[Cooke, Mark]

Dear List,

Can I ask your suggestions on how best to correct the following
scenario:

In a new repository we checked a version of the product code into
'trunk' (moving projects from VSS, finally).  This was cp'd to
'tags'/tag1.  A new svn user then cp'd 'tags'/tag1 to 'tags'/tag2 and
checked this out as a working copy:

[project] -> 'trunk'
'trunk' -> 'tags'/tag1
'tags'/tag1 -> 'tags'/tag2
'tags'/tag2 -> (wc)
(wc) -> 'tags'/tag2

Several updates later we have discussed the idea of what is a 'tag',
'branch' and the 'trunk' and have decided that the development should
have occurred in 'trunk' (small teams of one or two so no perceived need
for developer branches) and that we should create a new 'tags'/tag2 for
the release version.

How do we best achieve this, preserving as much history as possible?  I
can think of several possible solutions:

1) merge 'tags'/tag2 into trunk, delete 'tags'/tag2 then create new
'tags'/tag2 from trunk?

2) delete 'trunk', move 'tags'/tag2 to become 'trunk', create new tag

3) I'm sure I could think of worse ideas

I welcome your suggestions on the best solution.  We are hosting svn
1.6.6 on windoze server (via apache) and using latest tortoise from
windoze clients.  I have to admit that I've used svn pretty much as a
solo developer for several years now and never needed to branch/merge.
Now I find myself as admin for several small teams across departments
and in need of guidance.

Many thanks,

~ mark c

Re: How do I determine if svn:mergeinfo is corrupt and how would I fix it.

[Philip Martin]

Peter Kahn  writes:

> *Problems we are seeing:*
>
>1. changes not reported during trunk-to-branch merge show up in
>subsequent branch-to-trunk
>2. conflicts on svn:mergefinfo properties during merge
>3. file missing, but local edit on new file added in branch and pushed to
>trunk
>4. incoming + local delete (file deleted on trunk and branch shows as
>conflict)

(2) There is a recent bug fix in 1.6.11 that might be relevant
http://subversion.tigris.org/issues/show_bug.cgi?id=3573
but your description isn't detailed enough to say for sure.

(4) This is deliberate Subversion policy as Subversion cannot
distinguish between simple deletes and deletes that are part of a
move.  It's debatable whether this behaviour is correct, but it is
deliberate.  These conflicts are explicitly marked as delete-delete
conflicts so you should be able to detect and resolve them, perhaps
using a post-merge script.

-- 
Philip

Re: Subversion with mod_dav_svn (WebDAV) and large (binary) files

[Andy Levy]

Please don't post HTML-formatted messages.

On Tue, May 11, 2010 at 10:47, Marcus Scheller
 wrote:
> is a subversion-server with ‘mod_dav_svn module’ (http/https)   able to 
> handle large  (binary) files (> 2GB)?
>
> Are there any server/ os limitations?
>
> Are there client-limitations using a web-client  for checkin/checkout large 
> files (>2GB)
>
> I’ve heard that these browser has limits:
>
> IE6: 2GB
> IE7: 4GB
> IE8: no limit
> Firefox: 4GB
>
> Is SVN affected by these limitations?
>
> Maybe you can throw some light on this…

Subversion client operations are not performed via web browser, so any
limitations various web browsers have are not a factor.

Re: Best practice for moving folders around?

[Ulrich Eckhardt]

On Tuesday 11 May 2010, Cooke, Mark wrote:
> Can I ask your suggestions on how best to correct the following
> scenario:
>
> In a new repository we checked a version of the product code into
> 'trunk' (moving projects from VSS, finally).

Just for the record: There are tools that preserve some history, in case you 
care.


> This was cp'd to 'tags'/tag1.

A normal tagging operation, okay.


> A new svn user then cp'd 'tags'/tag1 to 'tags'/tag2 and 
> checked this out as a working copy:
>
> [project] -> 'trunk'
> 'trunk' -> 'tags'/tag1
> 'tags'/tag1 -> 'tags'/tag2
> 'tags'/tag2 -> (wc)
> (wc) -> 'tags'/tag2

Generally, tags are points in time, they are not intended for development and 
should be treated as immutable. There are even pre-commit hooks that enforce 
this. However, there is nothing that could stop the user from creating a 
working copy of it, only from committing to the repository.


> Several updates later we have discussed the idea of what is a 'tag',
> 'branch' and the 'trunk' and have decided that the development should
> have occurred in 'trunk' (small teams of one or two so no perceived need
> for developer branches) and that we should create a new 'tags'/tag2 for
> the release version.

Yes, development should have taken place either in trunk or in a separate 
branch. What you can do now depends on where you are and what you did in 
between

1. If "tag2" was not modified and trunk was not modified either (only local 
changes to the working copy), you could switch (svn switch) your working copy 
to the trunk and commit from there. You could then delete the tag, there 
isn't anything in there that happened anyway.

2. If the trunk was not modified, you could simply delete the project therein 
and move "tag2" in its place. Looking at the history, you will see that the 
location of the project jumps a bit around though, in case you care.

3. If the developer already committed his changes to the tag, and others 
committed to trunk, you should merge those changes into trunk instead. For 
that, you first declare the tag as a branch and move it to the "branches" 
folder. Then, you simply merge the revisions you want to the trunk. This is 
not different from the normal everyday merge that you do from a feature 
branch to your trunk and explained in the manual. Note that the developer 
must switch (svn switch) his working copy which still points at the tag, 
either at the branch or at trunk.


> How do we best achieve this, preserving as much history as possible?  I
> can think of several possible solutions:
>
> 1) merge 'tags'/tag2 into trunk, delete 'tags'/tag2 then create new
> 'tags'/tag2 from trunk?
>
> 2) delete 'trunk', move 'tags'/tag2 to become 'trunk', create new tag
>
> 3) I'm sure I could think of worse ideas

Actually, I would suggest merging the changes. Firstly, it documents that the 
changes were made in isolation. Secondly, it keeps the continuity of trunk. 
Lastly, you get familiar with branching and merging. In any case, you should 
delete or move "tag2", because it is not a tag.


> using latest tortoise from windoze clients.

Right-click, submenu, "Merge...". This will guide you through the merge 
process. Select "tag2" as source URL and a (clean) working copy of the trunk 
as target. Ignoring line ending and whitespace sometimes helps, or merging 
smaller ranges. Always merge and commit the root project folder, so you only 
have "svn:mergeinfo" property in one place.


Good luck!

Uli

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

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

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

Re: How do I determine if svn:mergeinfo is corrupt and how would I fix it.

[Stefan Sperling]

On Tue, May 11, 2010 at 03:53:20PM +0100, Philip Martin wrote:
> (4) This is deliberate Subversion policy as Subversion cannot
> distinguish between simple deletes and deletes that are part of a
> move.  It's debatable whether this behaviour is correct, but it is
> deliberate.

This is a problem with the current implementation.
Subversion does not currently know the difference between an incoming
rename and an incoming delete.

The options were to either flag no conflicts when renames are involved,
or flag false positive delete vs. delete conflicts. We chose the latter.

> These conflicts are explicitly marked as delete-delete
> conflicts so you should be able to detect and resolve them, perhaps
> using a post-merge script.

Any delete-delete conflict could be a rename-delete, rename-rename,
or a delete-rename conflict.
It's currently up to the user to find out which of these happened.

Blindly marking all delete vs. delete conflicts resolved is wrong
(unless you don't care about rename conflicts).

Stefan

Re: How do I determine if svn:mergeinfo is corrupt and how would I fix it.

[Philip Martin]

Stefan Sperling  writes:

> Blindly marking all delete vs. delete conflicts resolved is wrong
> (unless you don't care about rename conflicts).

As I said, it's debatable.  One could decide that since renames don't
exist they really are just copies and deletes.  In that case the
deletes don't conflict.

-- 
Philip

Free Online Subversion Training - All About Hook Scripts

[George Powell]

Hi all.



WANdisco is offering some free online training sessions over the next few
weeks, for any that are interested.  The topics will include:

* Introduction to Subversion for Developers - 5th May

* All About Subversion Hook Scripts - 19th May

* Using Subversion Locking - 2nd June

* All About Subversion Checkouts - 16th June

* Using the Subversion Diff Command - 30th June

* Branching and Merging in Subversion 1.6.9 - 14th July



Feel free to see the website for more information:

http://wandisco.com/webinar/subversion/training



I would recommend early registration as space may be limited.


Regards,



George Powell



T : +44 (0)114 3039985
F : +1 866-871-2009
W : http://www.wandisco.com



Free Online Subversion Training
http://svn.wandisco.com/eTraining



Join the Open Source Subversion Community
http://svn.wandisco.com/eCommunity



Follow us on Twitter
http://svn.wandisco.com/eTwitter



Join us on facebook!
http://svn.wandisco.com/eFacebook



Follow me on Facebook or Twitter!

http://www.facebook.com/home.php?#!/profile.php?id=11043426079

http://twitter.com/wandiscoGeorge



This email and any attachments may contain private, confidential and
privileged material for the sole use of the

intended recipient. If you are not the intended recipient, please
immediately delete this email and any attachments.

Subversion Exception will attempting to modify ignore list

[Miller, David D]

I use TortoiseSVN to access Subversion.  I'm reporting this here because the 
popup said to do so.

I attempted to add some files to the ignore list.  When I tried to commit the 
changes, Subversion said I had a tree conflict, but nothing I could do allowed 
me to resolve the conflict.  So I attempted to revert the ignores and got the 
following popup.

What other information and how to find it do you need?




David D. Miller
NCR SelfServ(tm) Checkout Software Architect
NCR Corporation
phone:770.623.7233
david.d.mil...@ncr.com | 
www.ncr.com


<>

Re: Subversion Exception will attempting to modify ignore list

[Stefan Sperling]

On Tue, May 11, 2010 at 02:05:47PM -0400, Miller, David D wrote:
> I use TortoiseSVN to access Subversion.  I'm reporting this here because the 
> popup said to do so.
> 
> I attempted to add some files to the ignore list.  When I tried to commit the 
> changes, Subversion said I had a tree conflict, but nothing I could do 
> allowed me to resolve the conflict.  So I attempted to revert the ignores and 
> got the following popup.
> 
> What other information and how to find it do you need?

Thanks, this is already known:
http://subversion.tigris.org/issues/show_bug.cgi?id=3469

Next time, please search the archives for the error message
you are getting (the pop-up also suggests to do so and provides
a link to the archives, though the svn.haxx.se one has a nicer
interface for search: http://svn.haxx.se/users).

Thanks,
Stefan

Re: How do I determine if svn:mergeinfo is corrupt and how would I fix it.

[Peter Kahn]

Thanks I have read that doc, but it was a while back so I'll re read it.

The issue with the problems we are seeing is that I'm coming in late to this
situation so most o of these I haven't seen first hand.   I also discovered
that people weren't using --reintegrate and push from branch to trunk.
That can easily result in extra conflicts.

Here's what I'm telling people to do now

PULL

svn co URL-branch path-to-workspace
svn mergeinfo URL-trunk path-to-workspace --show-revs eligible  >
eligible_revs.txt
svn merge --accept postpone URL-trunk path-to-workspace
svn mergeinfo URL-trunk path-to-workspace --show-revs eligible >
what-is-left-to-merge.txt

Repeat until there's nothing left that's eiligible.  The fact that the merge
sometimes stops and demands the user resolve before it can proceed with the
additional ranges through me for a bit.   I was still operating in 1.4
mental mode.   I didn't realize that SVN will break up the job based on the
merge history to as few merge ranges and paths as possible.  SVN will stop
merging if one of those creates a conflict and a subsequent needs to modify
the file.   (Makes complete sense, I can't postpone in that case).   I
believe that this case is what people were calling a conflict on mergeinfo
data.   So, the description wasn't accurate (at least I hope this is the
case).


PUSH

svn co URL-trunk path-to-workspace
svn mergeinfo URL-branch path-to-workspace --show-revs eligible  >
eligible_revs.txt

svn merge --reintegrate --accept postpone URL-branch path-to-workspace
svn mergeinfo URL-branch path-to-workspace --show-revs eligible >
what-is-left-to-merge.txt
... you may need to resolve conflicts and repeat the
... merge until there are no more change (see below for details)

svn ci -m "merge from trunk to branch using command: " local-path



I think the show-revs will give my users greater confidence about
determining when they are done.   We also plan to add a hudson build jobs
that checks the elibigle revision queue from trunk to each feature branch
and nags people if it gets too long.

On Tue, May 11, 2010 at 7:10 AM, Julian Foad wrote:

> Hi Peter.
>
> The mergeinfo "corruption" may be real, but just as likely it doesn't
> work the way you expect, or Subversion is being asked to perform
> combinations of merging that it doesn't support automatically.  It seems
> likely that even if there is some "corrupt" merge info, that is only a
> part of the problem.  It sounds like you might benefit from
> understanding better how Subversion's merging works "on the inside"
> which will give you the rationale for what it can and can't do "on the
> outside".
>
> If that's the case, have a look right at the end of this article
>  at
> the list of "Parting Thoughts" which says how to stick to the kinds of
> merging that Subversion can cope with.  (That article is mostly the
> intricate detail of svn:mergeinfo which you really don't want to know.)
> Also, WANdisco has an upcoming free training webinar on "Branching and
> Merging" which could be useful if you can wait till July 14:
> .
>
> As for the specific issues you mention, I can't comment much without
> seeing the precise detail.  It would be a good idea to raise each one as
> a separate query, giving a full transcript of input and output and what
> you think is wrong.
>
> Regards,
> - Julian
>
>
> --
Peter Kahn
citizenk...@gmail.com
pkahnp...@aim
http://www.google.com/profiles/citizenkahn
Awareness - Intention - Action

Re: How do I determine if svn:mergeinfo is corrupt and how would I fix it.

[Peter Kahn]

Thanks, I am not entirely sure what people were using for their push / pull
but I'm pushing a standard now.

I think we hit the following problems that made things worse:
- cherry pick merges + merges at levels below root (all are allowed, but
they can make later merges more complex)
- we assumed merge command completion meant all changes merged (didn't
double check with mergeinfo --show-revs eligible)
- possible bugs with earlier clients (1.5 or early 1.6).   We have many
ubuntu and debian systems and were unware of wandisco's update site
initially.  So, we missed out on the easy way to stay current.  We are now
rapidly deploying 1.6.11

PUSH

svn merge --reintegrate --accept postpone URL-branch path-to-workspace
svn mergeinfo URL-branch path-to-workspace --show-revs eligible  >
eligible_revs.txt
repeat until nothing left that's eligable

PULL
same pattern, but minus the --reintegrate


I'll go through our merge info data to see if there's anything that looks
like a problem and its not too large after anonimizing it  I'll post it for
review.

Thanks again,

On Tue, May 11, 2010 at 7:21 AM, Stefan Sperling  wrote:

> On Mon, May 10, 2010 at 12:12:49PM -0400, Peter Kahn wrote:
> > People use the this merge pattern
> >
> > a) PULL - merge trunk-to-branch, resolve, test, commit
> >
> > b) PUSH - merge branch-to-trunk, resolve, test, commit
> >
> > c) Recreate branch (or usually create new story branch and drop old since
> > it's done)
>
> PULL, PUSH, and Recreate branch could be anything.
> Can you describe the exact commands (or button clicks) you are using at
> each of these steps? Without that information it's pretty much impossible
> to tell what the root of your problem might be.
>
> Also, if you could provide your complete mergeinfo that would help:
>
>  svn propget -R -v svn:mergeinfo $REPOS_URL > allmergeinfo.txt
>
> Even if it's a lot of output, post all of it.
> You can do search/replace operations on pathnames which are
> confidential if you need to.
>
> Thanks,
> Stefan
>



-- 
Peter Kahn
citizenk...@gmail.com
pkahnp...@aim
http://www.google.com/profiles/citizenkahn
Awareness - Intention - Action

RE: long path names on windows prefixed with \\?\ not handled by svn commands

[Bert Huijben]

Subversion uses the APR library which handles the escaping for specific API
functions that allow this trick. The '\\?\' style paths are not a different
path, but just the original path escaped for a specific api. 

(Some Windows APIs allow this trick, others just support long paths directly
and then there are functions that support neither. By passing the long path
yourself you assume that all filesystem functions have this long path
support)

 

If you pass absolute paths to svn, it should support long paths directly.
(Windows doesn't support long relative paths). Subversion 1.7 will probably
work better with long relative paths, as it will use absolute paths
internally for almost every operation.

 

Bert

 

From: Heinz Prantner [mailto:heinz.prant...@opensynergy.com] 
Sent: dinsdag 11 mei 2010 14:21
To: users@subversion.apache.org
Subject: long path names on windows prefixed with \\?\ not handled by svn
commands

 

Hello,

 

running svn client commands other than svn checkout on windows fail,

if the path name (of the local working copy location) is prefixed with \\?\.

The prefix is required for path names longer than  255 or so.

  

It seems that svn commands like svn info or svn status behave different

than svn checkout command regarding the path name prefix.

 

example:

 

svn info \\?\c:\long\path\name

svn: '\' is not a working copy

 

Any thoughts?

 

(I am using svn client version 1.6.11 from CollabNet)

 

Thanks,

Heinz

 

 





 

Re: Cannot reintegrate feature branch

[Jean Seurin]

Stefan Sperling wrote:

On Tue, May 11, 2010 at 12:06:50PM +0800, Jean Seurin wrote:
   

Hi Stefan

first of all thanks for spending the time for this long thorough analysis.

1) I want to state that we're using a range of different SVN
clients, cli, Intellij Eclipse, mainly, and some people under
Windows may use Tortoise - bu those usually don't venture into
merges - yet.
I tought at first it could be the cause of the problem, since I have
had bad experiences with SVN clients on some IDEs.
But after reading through your whole analysis, I think I get where
the problem comes from. Here's our setup right now:

[copy]   [merge of bugfix r4 only]
   release-branch-1.13--r2---r4--
 /\
trunk   ---r1r3--r6--
   \\  \   / [--reintegrate not 
possible anymore]
 feature-branch-dev-r5--r7-
 [copy]   [merge]   [merge]

Hope the drawing make sense: we have to merge back bug fix from
/release branch/ back to trunk. We don't really have to use merge
command for that, but some developer start to take a fancy into it
and uses it to merge a revision only, that corresponds to a bug fix.
 


Can you state which revisions were merged where in your example?
I guess r2 is the commit which was not merged back into trunk?
How was the merge from release-branch-1.13 to trunk in r6 done?

   
You guessed right. I have been able to figure with the developer that 
commited the problematic merge how he actually did it: he used a 
"clever" integration function of Eclipse. He's got no clue what he did 
really and I'm not using Eclipse so I dont' either. I guess I'm not 
going to investigate further. I just told him to control hat he commits, 
not to commit empty files, but revert them instead.


I've created a new Feature branch from the trunk and copied the few 
commits by hand. It was faster in the end. But I'm really happy to have 
learn so much thanks to you.

If you want all changes that happened in the release branch
merged to trunk, you can use --reintegrate for that, since the merge
is going into the opposite direction to the branch copy.
But there's a catch: if you want to reintegrate multiple times (to merge
more bufixes later), you have to use the trick described here:
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice

   
That's a very good one to know. I guess, almost all modifications made 
on a Release branch (in our case at least) should made their way to the 
trunk. Except the one made on the pom.xml when releasing.

As far as i can see, for this reason only we need to do cherry picking.

Or you can do a cherry picking merge (grab one or more revisions
like your developer did). But cherry picking should only be done
into a single direction (mostly to keep things simple and prevent
developer insanity, but also because it makes merging with svn easier).
So if you ever cherry-picked one way, do not cherry pick the other way.

The canonical way to do the cherry-pick would be:
  cd trunk-working-copy
  svn merge -c 6 ^/release-branch-1.13

   

If I follow you - and that would make sense - once this merge to
trunk makes its way to the /feature branch/, this one becomes not
'reintegratable' anymore.
 


It depends. I'm still not entirely sure I understand your example.
If you could describe how each of the merges was (reintegrate merge,
sync merge, cherry-pick merge) that would help.

   

This use case appears to be quite regular to me. If it is not
possible to use it, it'd be better to know it before using /Feature
branch.
 


It is possible to use features branches and release branches at
the same time. Merging bug fixes from the release branch to the
trunk should not prevent reintegration of the feature branch.
That alone does not explain the problem.

   
I'm very glad to know that, I was afraid that scenario wouldn't be 
supported by SVN. We definitely need that for the reasons I mentioned above.

I still think it's more likely that your problem is due to the
scattered subtree mergeinfo on trunk and possible the project-dev
branch. The mergeinfo shows "holes" in the merge history between
project-dev and trunk. These holes need to be filled before project-dev
is ready for reintegration.

I don't think a single cherry-picking merge from an unrelated branch
would cause this problem.

   

/2) How can I solve my problem?
It seems from the reasoning above that the right solution would be
to do a complete merge of the Release branch 1.13 to the trunk -
instead of just a revision. I doubt that is possible for us.
If not, what are the options left? /
 


Making sure merges into your project-dev branch from trunk cover
a continuous revision range is your best option I think.

   

Maybe o all the merges myself ! But that's a lot of work...

/I want to get rid of the su