AW: Changes are getting clobbered when working on remote svn files
Hi, Georg, > It's due to - he has PHP 5.2x on his local and doesn't want to upgrade it > (for supporting another older PHP4x site with certain config) and we have PHP > 5.3x with some required other extensions on the dev server - so that's the > reason for doing it this way in only his case. Maybe he should install both PHP versions in parallel locally. And even the need to synchronize his directory to the server to execute it in PHP there does not force him to have the working copy there. He could have his working copy locally, so he can update and commit there in the normal way, and use some script (maybe using rsync, or ftp) to synchronize it to the dev server just for execution. This even saves him the step to re-synchronize it back to his local machine after update. Mit freundlichen Grüßen Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Entwicklung Memminger Str. 151 | 87439 Kempten | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys Internet-Forum: http://forum.3s-software.com Geschäftsführer: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Handelsregister: Kempten HRB 6186 | USt-IDNr.: DE 167014915 Von: Geoff Hoffman [mailto:ghoff...@cardinalpath.com] Gesendet: Donnerstag, 1. September 2011 22:40 An: Konstantin Kolinko Cc: users@subversion.apache.org Betreff: Re: Changes are getting clobbered when working on remote svn files
Re: Could not initialize the SASL library
On Thu, Sep 1, 2011 at 6:42 PM, Adam Paeth wrote: > I'm hoping someone has some idea what happened here. > I had a working subversion server. However after a mishap with yum some of > the supporting packages like sasl and ssh were removed. I've re-installed > all the packages that were removed, but for some reason any time I run > svnserve or try to use svn over ssh I get the following: > svn: Couldn't perform atomic initialization > svn: Could not initialize the SASL library > svn: generic failure > > If anyone has any idea what the problem is or where I can look to get more > details that would be greatly appreciated. I've been able to verify the > repository files so it seems to be a system configuration problem and > without any additional error information I'm a bit stuck. You might have a /var/log/yum.log showing the problematic changes. If you have 3rd party yum repositories enabled, maybe there are some conflicts with the base distribution. -- Les Mikesell lesmikes...@gmail.com
Could not initialize the SASL library
I'm hoping someone has some idea what happened here. I had a working subversion server. However after a mishap with yum some of the supporting packages like sasl and ssh were removed. I've re-installed all the packages that were removed, but for some reason any time I run svnserve or try to use svn over ssh I get the following: svn: Couldn't perform atomic initialization svn: Could not initialize the SASL library svn: generic failure If anyone has any idea what the problem is or where I can look to get more details that would be greatly appreciated. I've been able to verify the repository files so it seems to be a system configuration problem and without any additional error information I'm a bit stuck. Thanks, Adam Paeth
Re: Build needs to mkdir serf/auth in the build root.
serf is an external library; it is not part of Subversion itself. Please report this issue to the serf maintainers at their mailing list --- the address should be in README or INSTALL in the serf source tree (ie, ./serf/). Thanks. On Thu, 01 Sep 2011 11:10 -0700, "David Elliott" wrote: > Configured with subversion-1.7.0-rc2-BUILD build root as a sibling of > subversion-1.7.0-rc2 source root. > > Looks like serf/auth needs to be made inside the build directory if the build > is to work. A minor annoyance, easily fixed by running mkdir serf/auth > before make. Might be that I'm making with very high parallelism (j16). > > The below log is of simply running make after it has failed once in > high-parallelism mode to see what the actual problem is. > > -Dave > > > $ make > -- making all in apr > make[2]: Nothing to be done for `local-all'. > -- completed all in apr > -- making all in apr-util > make[2]: Nothing to be done for `local-all'. > -- completed all in apr-util > -- making all in serf > /Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2-BUILD/apr/libtool > --silent --tag=CC --mode=compile gcc -g -O2 -DDARWIN > -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp > -I/Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2/serf > -I/Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2-BUILD/apr/include > -I/Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2/apr/include > -I/Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2-BUILD/apr-util/include > -I/Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2/apr-util/include > -c -o auth/auth.lo > /Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2/serf/auth/auth.c && > touch auth/auth.lo > /Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2-BUILD/apr/libtool: > line 1280: auth/auth.loT: No such file or directory > mkdir: auth: No such file or directory > make[1]: *** [auth/auth.lo] Error 1 > make: *** [external-all] Error 1 > >
Re: Changes are getting clobbered when working on remote svn files
On Thu, Sep 1, 2011 at 1:38 PM, Ryan Schmidt < subversion-20...@ryandesign.com> wrote: > On Sep 1, 2011, at 13:52, Geoff Hoffman wrote: > > > I thought I would send this to the list to see if others have experienced > similar issues; and as a warning to look out for this scenario. > > What this should serve as is a reminder to all developers to use "svn diff" > (or GUI equivalent) every time before you commit, to make sure the changes > you're about to commit are actually the ones you intended to make. I'm > almost certain your developer is overwriting a newer file with an older file > via his FTP client or IDE, and is not noticing because he's not checking the > diff. > > The trouble here is that, the IDE is pushing a new version back to the remote server where svn is running, which is where the changes are are being lost. I think a solution isn't possible. What needs to happen is that when you save a local version, the IDE should issue svn up on the remote server to check for conflicts but it can't because it has only an FTP connection available to it. Even if he logs in via SSH to the server and issues svn up on the remote files (getting -r 400 of x/y.php correctly on the remote box), the IDE with his changes to -r395 isn't smart enough to know that the file has changed remotely (although it should, IMO, download a tmp copy to check before ftp sync). There is most certainly a method to operate in this fashion safely, however it requires more manual steps to be followed meticulously. It's probably safe to say that creating and working on a "remote project" is best suited for a single developer (with svn running locally on the downloaded project files) versus running svn on the remote machine. We also had the idea to mount the project via Go -> Connect to Server... and use svn "locally" on /Volumes/devserver/project but this is untested.
Build needs to mkdir serf/auth in the build root.
Configured with subversion-1.7.0-rc2-BUILD build root as a sibling of subversion-1.7.0-rc2 source root. Looks like serf/auth needs to be made inside the build directory if the build is to work. A minor annoyance, easily fixed by running mkdir serf/auth before make. Might be that I'm making with very high parallelism (j16). The below log is of simply running make after it has failed once in high-parallelism mode to see what the actual problem is. -Dave $ make -- making all in apr make[2]: Nothing to be done for `local-all'. -- completed all in apr -- making all in apr-util make[2]: Nothing to be done for `local-all'. -- completed all in apr-util -- making all in serf /Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2-BUILD/apr/libtool --silent --tag=CC --mode=compile gcc -g -O2 -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I/Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2/serf -I/Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2-BUILD/apr/include -I/Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2/apr/include -I/Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2-BUILD/apr-util/include -I/Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2/apr-util/include -c -o auth/auth.lo /Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2/serf/auth/auth.c && touch auth/auth.lo /Users/dfe/SourceBuilds/subversion/subversion-1.7.0-rc2-BUILD/apr/libtool: line 1280: auth/auth.loT: No such file or directory mkdir: auth: No such file or directory make[1]: *** [auth/auth.lo] Error 1 make: *** [external-all] Error 1
Re: Changes are getting clobbered when working on remote svn files
On Thu, Sep 1, 2011 at 12:24 PM, Konstantin Kolinko wrote: > 2011/9/1 Geoff Hoffman : > > We have a mixed development environment (Mac, Win, Linux). > > We have an SVN 1.6 repo on the LAN (Ubuntu server 10.04 LTS). > > We have a development server on the LAN (Ubuntu server 10.04 LTS). > > (I don't think any of the hardware or software matters in this case, but > > here it is anyway) > > Most of us are running fully-local checkout working copies, editing hosts > > file, NameVirtualHost on, using Netbeans, Textmate (Mac), Notepad++ on > Win. > > One of our developers "A" is storing his working copy checked out onto > the > > dev server and uses netbeans FTP to work on the files. > > What we found is that he is somehow able to overwrite newer files in the > > repository if he edits the same file. > > In other words, if developer "B" changes file x/y.php at -r 400 and dev > "A" > > has checked out and is working on file x/y.php at -r 395 then when dev > "A" > > commits x/y.php at -r 405 it does not include "B"'s changes from -r 400. > > We are guessing that either: > > - he didn't svn up on the dev server; (claims he always does, of course) > > If you had access logs enabled on your server, you could verify it. > > > - he didn't 'refresh folder' to grab the latest stuff from his > > checkout/update > > - he has a "local cached copy" he downloaded from the dev server to edit > - > > and somehow his IDE (NetBeans 6.9) is not realizing that the remote files > > have changed. > > or some combination thereof. > > One would assume that remote server development and version control would > > have been sorted out long ago and developer "A" should be getting a > conflict > > on commit, or a merge event at commit time, but this isn't the case. > > What we now believe is that: > > When saving to a remote project, FTP is overwriting the file, even if it > has > > been svn updated manually, > > That is very likely to happen. If you just transfer a file it will > likely to overwrite remote one, regardless of what changes have been > there. > Yes it's almost certainly a problem with either FTP or the IDEs implementation of that, not SVN. > Why your developer is editing the file remotely if you have svn? > Check it out locally, edit locally, commit locally and then go to > remote server and svn up there. > It's due to - he has PHP 5.2x on his local and doesn't want to upgrade it (for supporting another older PHP4x site with certain config) and we have PHP 5.3x with some required other extensions on the dev server - so that's the reason for doing it this way in only his case. > > BTW, you may ask on NetBeans forums, how the tool behaves. > > I think I will - I had thought of that, it maybe a bug in NetBeans (or a feature improvement request) although another developer here tried something similar with Coda and the same thing happens. > > and upon commit, it just sees the ftp-overwritten > > file as the newest regardless of the change at -r 400. > > I thought I would send this to the list to see if others have experienced > > similar issues; and as a warning to look out for this scenario. > > Best regards, > Konstantin Kolinko >
Re: Changes are getting clobbered when working on remote svn files
On Sep 1, 2011, at 13:52, Geoff Hoffman wrote: > I thought I would send this to the list to see if others have experienced > similar issues; and as a warning to look out for this scenario. What this should serve as is a reminder to all developers to use "svn diff" (or GUI equivalent) every time before you commit, to make sure the changes you're about to commit are actually the ones you intended to make. I'm almost certain your developer is overwriting a newer file with an older file via his FTP client or IDE, and is not noticing because he's not checking the diff.
Re: Changes are getting clobbered when working on remote svn files
2011/9/1 Geoff Hoffman : > We have a mixed development environment (Mac, Win, Linux). > We have an SVN 1.6 repo on the LAN (Ubuntu server 10.04 LTS). > We have a development server on the LAN (Ubuntu server 10.04 LTS). > (I don't think any of the hardware or software matters in this case, but > here it is anyway) > Most of us are running fully-local checkout working copies, editing hosts > file, NameVirtualHost on, using Netbeans, Textmate (Mac), Notepad++ on Win. > One of our developers "A" is storing his working copy checked out onto the > dev server and uses netbeans FTP to work on the files. > What we found is that he is somehow able to overwrite newer files in the > repository if he edits the same file. > In other words, if developer "B" changes file x/y.php at -r 400 and dev "A" > has checked out and is working on file x/y.php at -r 395 then when dev "A" > commits x/y.php at -r 405 it does not include "B"'s changes from -r 400. > We are guessing that either: > - he didn't svn up on the dev server; (claims he always does, of course) If you had access logs enabled on your server, you could verify it. > - he didn't 'refresh folder' to grab the latest stuff from his > checkout/update > - he has a "local cached copy" he downloaded from the dev server to edit - > and somehow his IDE (NetBeans 6.9) is not realizing that the remote files > have changed. > or some combination thereof. > One would assume that remote server development and version control would > have been sorted out long ago and developer "A" should be getting a conflict > on commit, or a merge event at commit time, but this isn't the case. > What we now believe is that: > When saving to a remote project, FTP is overwriting the file, even if it has > been svn updated manually, That is very likely to happen. If you just transfer a file it will likely to overwrite remote one, regardless of what changes have been there. Why your developer is editing the file remotely if you have svn? Check it out locally, edit locally, commit locally and then go to remote server and svn up there. BTW, you may ask on NetBeans forums, how the tool behaves. > and upon commit, it just sees the ftp-overwritten > file as the newest regardless of the change at -r 400. > I thought I would send this to the list to see if others have experienced > similar issues; and as a warning to look out for this scenario. Best regards, Konstantin Kolinko
Re: Trunk for "Prod" and a branch for "dev"
On Thu, Sep 1, 2011 at 12:25 PM, Brendan Flanagan wrote: > All, > > One of our customers is implementing subversion and TSVN and they have > decided on a repository structure that is slightly different than "the norm" > and I wanted to check if it had any "flaws"? > > They support and develop enhancements to a purchased product (they don't > have the source for the purchased product, only their enhancements). > > They want "trunk" to reflect the current Production Release of their > enhancements only. They intend creating a branch called "Development" that > the small number of developers will use day to day - i.e. they will add new > enhancements, change existing code etc. Things like this make David sad... Managers and consultants love this idea because it sounds so good. Then, the idea is you keep replacing "development" with what is in "trunk" every time you start new development. After all, you know that trunk is what's in production! There are many things wrong with the idea. One is that you're constantly copying and tagging and you're going to get lost. Someone is going to forget to copy the tag to trunk. Then, when a bug is found in production, you'll be basing it on the wrong release. Tagging is skipped because it's a production bug and you're in a hurry. Plus, your release procedure is inconsistent, Sometimes, you're releasing from trunk, sometimes from a release branch, sometimes from development. Sometimes tags are made, sometimes they're not. Also notice what happens: 1). Development is done on "development" 2). A release is done and is tagged by copying "development to the "tags" directory. 3). That tag is copied to "trunk" because that's what's in production. 4). Production is copied back to "development" when new work needs to be done. Notice you're copying from development to tags to trunk and back to development. Now, you are working on development and find a bug in production. You fix it in "trunk" because that's what is in production. However, copying production to development won't work. You'll lose development work. However, the circular motion of all that copying is going to cause all sorts of merge issues. And, what about file history? The development history of development/foo.c isn't straight forward. What you see is a copy from trunk which was copied from tags which was copied from an older version of the development branch that was replaced when you copied trunk to development. There's a reason why we do development in trunk, copy trunk to a release branch, and then tag from the branch. It's easy to track what's going on, and if you need to merge a bugfix from a release into development, it's easy to do. The copying is only done in a single direction. The history is clear, and the release procedure is repeatable. Plus, you'll get in the habit of tagging anything that goes into production. Is it that they just want to see what's in production? Why not create a special PRODUCTION tag? $ svn cp %REPOS%/module/tags/%TAG% %REPOS%/module/tags/PRODUCTION This way, development is still straight forward, and you can even view the history of what's in production via: $ svn log %REPOS%/module/tags/PRODUCTION" You'll see what release is in production, and the complete history of all releases, when they were placed in production, etc. -- David Weintraub qazw...@gmail.com
Changes are getting clobbered when working on remote svn files
We have a mixed development environment (Mac, Win, Linux). We have an SVN 1.6 repo on the LAN (Ubuntu server 10.04 LTS). We have a development server on the LAN (Ubuntu server 10.04 LTS). (I don't think any of the hardware or software matters in this case, but here it is anyway) Most of us are running fully-local checkout working copies, editing hosts file, NameVirtualHost on, using Netbeans, Textmate (Mac), Notepad++ on Win. One of our developers "A" is storing his working copy checked out onto the dev server and uses netbeans FTP to work on the files. What we found is that he is somehow able to overwrite newer files in the repository if he edits the same file. In other words, if developer "B" changes file x/y.php at -r 400 and dev "A" has checked out and is working on file x/y.php at -r 395 then when dev "A" commits x/y.php at -r 405 it does not include "B"'s changes from -r 400. We are guessing that either: - he didn't svn up on the dev server; (claims he always does, of course) - he didn't 'refresh folder' to grab the latest stuff from his checkout/update - he has a "local cached copy" he downloaded from the dev server to edit - and somehow his IDE (NetBeans 6.9) is not realizing that the remote files have changed. or some combination thereof. One would assume that remote server development and version control would have been sorted out long ago and developer "A" should be getting a conflict on commit, or a merge event at commit time, but this isn't the case. What we now believe is that: When saving to a remote project, FTP is overwriting the file, even if it has been svn updated manually, and upon commit, it just sees the ftp-overwritten file as the newest regardless of the change at -r 400. I thought I would send this to the list to see if others have experienced similar issues; and as a warning to look out for this scenario. Cheers - Geoff
Re: Trunk for "Prod" and a branch for "dev"
On Thu, Sep 1, 2011 at 11:25 AM, Brendan Flanagan wrote: > > They support and develop enhancements to a purchased product (they don't > have the source for the purchased product, only their enhancements). > > They want "trunk" to reflect the current Production Release of their > enhancements only. They intend creating a branch called "Development" that > the small number of developers will use day to day - i.e. they will add new > enhancements, change existing code etc. The nature of the product may make this unlikely, but what happens when/if they need to concurrently support and fix bugs in more than one release version - that is, if either the base product branches, or all of their customers can't or won't upgrade to their latest at the same time? While subversion itself doesn't really care about the directory names, if you release from branches it is obvious that you can have several active concurrently, but you normally only ever have one trunk. -- Les Mikesell lesmikes...@gmail.com
Re: Trunk for "Prod" and a branch for "dev"
On Sep 1, 2011, at 18:25 , Brendan Flanagan wrote: > All, > > One of our customers is implementing subversion and TSVN and they have > decided on a repository structure that is slightly different than "the norm" > and I wanted to check if it had any "flaws"? > > They support and develop enhancements to a purchased product (they don't > have the source for the purchased product, only their enhancements). > > They want "trunk" to reflect the current Production Release of their > enhancements only. They intend creating a branch called "Development" that > the small number of developers will use day to day - i.e. they will add new > enhancements, change existing code etc. > > Periodically they will merge some of the committed changes (from the Dev > branch) back to trunk and effectively create a new "Production Release" and > tag it. > > On the face of it I can't see anything wrong with this approach and it's > different than others we use/have seen and doesn't follow the recommended > approach of developing in the trunk and creating release branches - but is > this structure/process going to cause any heartache for them? I guess it > just doesn't feel right as it's different than anything we have seen before > but I am struggling to come up with a strong argument against it. > If some percentage of changes on the development branch never get merged to trunk, then that branch will slowly diverge from the trunk. The developers would need to reverse any revisions on their branch that have been rejected by testers. That's not as easy as it sounds, since reverse-merging old revisions often leads to conflicts. If the team is small and the code is stable, it's doable. Otherwise, there's too much manual diff- and log-inspection. Also, if they decide later to have more than one development branch, it will be difficult to share changes among the branches. You'll likely see cyclical merging, which doesn't work well in Subversion's model. Or developers will integrate very late, which is risky. Regards, Steve -- Stephen Butler | Senior Consultant elego Software Solutions GmbH Gustav-Meyer-Allee 25 | 13355 Berlin | Germany tel: +49 30 2345 8696 | mobile: +49 163 25 45 015 fax: +49 30 2345 8695 | http://www.elegosoft.com Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Trunk for "Prod" and a branch for "dev"
All, One of our customers is implementing subversion and TSVN and they have decided on a repository structure that is slightly different than "the norm" and I wanted to check if it had any "flaws"? They support and develop enhancements to a purchased product (they don't have the source for the purchased product, only their enhancements). They want "trunk" to reflect the current Production Release of their enhancements only. They intend creating a branch called "Development" that the small number of developers will use day to day - i.e. they will add new enhancements, change existing code etc. Periodically they will merge some of the committed changes (from the Dev branch) back to trunk and effectively create a new "Production Release" and tag it. On the face of it I can't see anything wrong with this approach and it's different than others we use/have seen and doesn't follow the recommended approach of developing in the trunk and creating release branches - but is this structure/process going to cause any heartache for them? I guess it just doesn't feel right as it's different than anything we have seen before but I am struggling to come up with a strong argument against it. Any comments are much appreciated. Thanks, Bren
RE: Really lousy performance with svn info --depth infinity
Very well, we'll move it to users. I just figured it was a bug in 1.7 since
the performance of the svn info -depth infinity was SIGNIFICANTLY faster in
1.6.x. Currently it takes 1 minute with 1.7 and less than a second with 1.6.x.
-Mike
From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: Thursday, September 01, 2011 9:43 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1); d...@subversion.apache.org
Subject: RE: Really lousy performance with svn info --depth infinity
These operations do very different things. The first reads your working copy to
obtain a lot of details (unless you pass a revision; in that case it looks at
the repository)
The second asks the repository what files there are below the current directory
in the repository (using the revision of the current directory).
In my usage (repository hosted via http:// on the other side of the world) the
second is much slower... But if you have a local repository the opposite might
be true.
I think this question belongs on users{_AT_}subversion.apache.org though, as it
is about using Subversion and not on Subversion development.
Bert
From: michael_rytt...@agilent.com [mailto:michael_rytt...@agilent.com]
Sent: donderdag 1 september 2011 17:26
To: d...@subversion.apache.org
Subject: Really lousy performance with svn info --depth infinity
Hi guys,
Quick question. I would expect the following 2 commands to perform equivalent
functions.
svn info -depth infinity
svn ls -depth infinity | xargs svn info
This issue is that the first command takes 1 minute to run while the second
command takes 6 seconds to run. I am running 1.7.0-rc2.
-Mike
