"svn diff" works for added files in working copy, but not for previous revision
Hi, When I do "svn diff file1" on a file that I just added to my working copy since the last commit, it prints a diff that shows the entire file being added. However, if I had a file that was added in a previous revision (say 42), and I try to do "svn diff -c 42 file2", it doesn't work. It gives the error: svn: Unable to find repository location for 'file2' in revision 41 Of course, it is true that the file did not exist in revision 41. But all I want is to see the same diff information as I get from a working copy, i.e. a diff that shows the added file in revision 42. Is there a way I can do that?
can i svn cat without keyword expansion
Hi, If I do "svn cat" on a file, with the svn:keywords property set, it expands out SVN keywords such as $Date$, $Revision$, $Id$, etc., in the file (the ones there were included in the svn:keywords property anyway). Is there an option that will NOT do the expansion? Or is there some other way of using the svn client that will achieve the same thing? As I understand, the file is stored in the repository with keywords not expanded, and the client expands them when it retrieves them, so shouldn't it be trivial to have a functionality to skip this step? Thanks,
RE: Why doesn't 'svnadmin create' creates tags, branches, trunk?
> > From: Tech Geek [mailto:techgeek12...@gmail.com] > > > > So why don't we have (read as a feature) something like this: > > > > # svnadmin create --tbt new_repo > > > > and a repositroy with following strcuture is created > (automatically) > > > > # ls /var/lib/svn/new_repo > > branches > > tags > > trunk > > I have several repositories of my own, and I support several more, > for > various companies that I work for. None of them have the branches > & tags at > the top level of the repo, because the repo actually contains many > separate > independent projects. You should stick your branches & tags dir at > whatever > levels of the tree you'd be interested in branching & tagging. > > If you did the -tbt switch, it's just a lazy way to eliminate a > single "svn > mkdir" after the "svnadmin create." Not really worth while, imho. > If you > can remember the "-tbt" then you can remember the "svn mkdir." Create a template repository with the folders you want in it. Then dump it. Save that file somewhere. After you create a repo you can do an svnadmin load --ignore-uuid < templatedumpfile (so you retain the unique uuid in the newly created repo). You can even create a batch/command for this to do it with one command. BOb
RE: svn Farm
> Le 06/10/2010 17:06, Siva Kumar a écrit : > >> I need to provide svn service to many small groups of students. > >> I'am looking for a tool that would help industrialize managment > of > >> repositories. > >> I don't want to issue hundreds of "svn create", "vi authz" , > edit ssh keys > >> for svn+ssh access etc ... > >> Are there such tools already existing ? > > Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might > fit your bill. > good point ! > I've installed and run it, looks good. > but now I need to find a way to link my ldap users to svn > roles/authz , > I still can't find how to do that wihout creating csvn local > accounts > for all my users :-( ... !? Oh man, I thought edge did that for you and provided a web UI to set it up. Which is why I was considering moving to it when 1.7 came out. Not so? BOb
RE: svn Farm
> Now, is collabnet solution able to serve tradition unix shell > comand > line clients ? is there a svnserve server behind it or is apache > able to > serve those clients using svn protocol too ? BTW: If you have http(s) access you don't also need svn protocol. The svn command line client supports http(s) just fine. BOb
RE: User authentication\authorization upper-lower case
> Hi all. I have a problem with SVN. I have the (only) user > 'test_user' (in the 'passwd' file) having 'rw' on the entire > repository. Why am I able to get *authenticated* with the user > 'TESTUSER' (but not *authorized* to commit)? Note that only > authenticated user can access and read from my repository, so > 'TESTUSER' should not be authenticated, as it happens for all the > users not appearing in the passwd file, for example the 'BlaBlaBla' > user. > Thanks You probably have anon access allowed. Are you using svn or apache/http? Perhaps showing us your config file would help. I think authorization is only applied to authenticated users. BOb
RE: svn Farm
> Le 08/10/2010 15:59, Bob Archer a écrit : > >> Now, is collabnet solution able to serve tradition unix shell > >> comand > >> line clients ? is there a svnserve server behind it or is apache > >> able to > >> serve those clients using svn protocol too ? > > BTW: If you have http(s) access you don't also need svn protocol. > The svn command line client supports http(s) just fine. > > > > BOb > Damn it ! I didn't realized it was possible ... I though svn > command > line tool could only talk to svnserve (svn or svn+ssh URLs) . > Indeed, svn + ldaps URL might simplify my project . > However, I already see a usage diffulty, any time I issue a svn > command > line, I'am asked to enter my password (apache authN !) , is there a > workaround to that authN password call ? > with svn+ssh I could push ssh public keys once for all . > > thanks . The client should be able to store the credentials if you have it set up to do so. On windows/mac it is encrypted with OS included libraries. For Linux you need to set up gnome keyring or kde-wallet. http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.netmodel.credcache BOb
RE: User authentication\authorization upper-lower case
> >> Hi all. I have a problem with SVN. I have the (only) user > >> 'test_user' (in the 'passwd' file) having 'rw' on the entire > >> repository. Why am I able to get *authenticated* with the user > >> 'TESTUSER' (but not *authorized* to commit)? Note that only > >> authenticated user can access and read from my repository, so > >> 'TESTUSER' should not be authenticated, as it happens for all > the > >> users not appearing in the passwd file, for example the > 'BlaBlaBla' > >> user. > >> Thanks > >You probably have anon access allowed. Are you using svn or > apache/http? Perhaps showing us your config file would help. I > >think authorization is only applied to authenticated users. > > >BOb > > anon-access = none > password-db = passwd > authz-db = authz > > I'm using svn (svnserve.exe). There is a mistake in the previous > post: 'test_user' is without the '_' character. So the only user in > passwd is 'testuser'. Every user different from 'testuser' does not > get authentication, while 'TESTUSER' gets authentication, but he's > not authorized to commit. (while 'testuser' is). It seems that > 'TESTUSER' and 'testuser' are the same from the authentication > point of view, while they are different from the authorization > point of view. Instead, I would expect for 'TESTUSER' to not be > authenticated. Am I right or am I missing something? Thanks. > On Fri, Oct 8, 2010 at 4:51 PM, Bob Archer > wrote: You are possibly correct. I know that svn is case sensitive. However, the authentication may not be. If you authenticate using lower case can you do your commit? BOb
RE: User authentication\authorization upper-lower case
> On Fri, Oct 8, 2010 at 5:30 PM, Bob Archer > wrote: > > >> Hi all. I have a problem with SVN. I have the (only) user > > >> 'test_user' (in the 'passwd' file) having 'rw' on the entire > > >> repository. Why am I able to get *authenticated* with the user > > >> 'TESTUSER' (but not *authorized* to commit)? Note that only > > >> authenticated user can access and read from my repository, so > > >> 'TESTUSER' should not be authenticated, as it happens for all > > the > > >> users not appearing in the passwd file, for example the > > 'BlaBlaBla' > > >> user. > > >> Thanks > > >You probably have anon access allowed. Are you using svn or > > apache/http? Perhaps showing us your config file would help. I > > >think authorization is only applied to authenticated users. > > > > >BOb > > > > anon-access = none > > password-db = passwd > > authz-db = authz > > > > I'm using svn (svnserve.exe). There is a mistake in the previous > > post: 'test_user' is without the '_' character. So the only user > in > > passwd is 'testuser'. Every user different from 'testuser' does > not > > get authentication, while 'TESTUSER' gets authentication, but > he's > > not authorized to commit. (while 'testuser' is). It seems that > > 'TESTUSER' and 'testuser' are the same from the authentication > > point of view, while they are different from the authorization > > point of view. Instead, I would expect for 'TESTUSER' to not be > > authenticated. Am I right or am I missing something? Thanks. > > On Fri, Oct 8, 2010 at 4:51 PM, Bob Archer > > wrote: > You are possibly correct. I know that svn is case sensitive. > However, the authentication may not be. If you authenticate using > lower case can you do your commit? > > BOb > > Sure, 'testuser' can commit So, it sounds like you have your answer. Authentication is not case sensitive, yet authorization is. Seems like a bit of a bug to me. Perhaps a svn dev will jump in here and let us know. BOb
RE: svndump filter: How to pretend files were added to trunk
> Hi there ! > > I am trying to cleanup my SVN history. Back in the beginning of > the > project I started using SVN without the standard layout (trunk, > branches, tags parent dir). Now using svndumpfilter, I would like > to > pretend that initial history [r1-1097] did happen within the trunk > directory. For that I use svnadmin dump and then play with node- > path > using sed: > > cat initial.dump | sed -e 's,^Node-path: Applications,Node-path: > trunk/Applications,' -e 's,^Node-copyfrom-path: > Applications,Node-copyfrom-path: trunk/Applications,' > clean.dump > > Since trunk directory did not exist I tried doing: > > svnadmin create clean > svn mkdir -m"Initial project roots" file://`pwd`/clean/trunk > svnadmin load --quiet --ignore-uuid clean < clean.dump > > However it fails with: > > svnadmin: File not found: transaction '835-n7', path > 'trunk/Applications' > > Now if do: > > svnadmin create clean > svn mkdir -m"Initial project roots" file://`pwd`/clean/trunk > svn mkdir -m"Initial project roots" > file://`pwd`/clean/trunk/Applications > svnadmin load --quiet --ignore-uuid clean < clean.dump > > It fails with: > > svnadmin: File already exists: filesystem 'clean/db', transaction > '184-55', path 'trunk/Applications' > > Am I missing something ? Is there a tool to re-root a bunch of > files/directories that were not initially created within a 'trunk' > dir > ? > If you are putting this into the same repository why not just export the stuff then import it into the path you would like it to reside? This will begin the history for that new path. BOb
RE: Need advice on when to commit and how many commits to issue when multiple files changed
> David Weintraub gmail.com> writes: > > > > > On Wed, Oct 13, 2010 at 2:25 AM, LiuYan 刘研 > 21cn.com> wrote: > > > Hi all, > > > Because a single svn commit will result in a whole new revision > tree, so > > > currently I commit all changes once per day after work (to > avoid too many > > > revisions because of my old CVS habit). > > > > > > But I'm afraid it's not a proper way, so: > > > > Commits should be done as part of a set of changes. Think of it > this > > way, you are repairing Bug #123, and to do that, you have to > modify > > four files. Those four files and only those four files should be > > committed together as a fix for Bug #123. > > > > This way, if there is some reason to back out this change, it is > easy > > to locate and do. One of the biggest reasons to use Subversion > over > > CVS is when it comes to backing out a change. > > > > In order to backout a change in CVS, I first have to find all of > the > > files changed which can be difficult. In CVS, all files are > versioned > > separately. Doing a cvs log is unwieldy. It's one of the reasons > we > > would tag after each CVS build. > > BTW, CVS tagging is very nice, 'tagging' (svn copy) in subversion > is like an > extra commit and result in a new revision, although 'svn copy' is a > light/cheap > way in subversion, it still make me confused sometimes. > > I remember there's feature request about this, maybe called > 'labeling' or > something like that, wish it can be implemented in future > subversion version. No thank you. Since "tagging" is usually done at the file level and it can take forever. Yes you get an difference rev number in svn when you "tag" but um... frankly I ignore the rev numbers in svn. TSVN makes that very easy to do. You'll get used to it quickly and probably prefer it too. BOb
RE: Managing modifications to an open source product
> I develop for a site that uses Mediawiki (MW). We make some > modifications to it before deployment. Generally, (using > subversion) we check out a tagged version into a workspace, > recursively delete the .svn directories, modify a small number of > files, add some of our own extensions, and then commit the result > into our own repository. We then work with the source from there. > > This approach means we have to track MW bug-fixes and add them to > our modified version. I was wondering if there is a better way to > accomplish the same objective. For example, we can use the > svn:externals property to point to the MW repository version of the > extensions we use, so each time they are updated, all we need to do > is svn up on the externals directory. > > The main source is a different story. Since we modify some of the > files (and have no commit privileges to the MW repository), the > files we modify are not within our purview to change (and > understandably the MW people wouldn't allow it even if we had > commit privileges). > > Is there any way to use the svn:externals property to solve the > main source issue? For example, could we point the revision we keep > in our main repository to the correct revision in the MW repository > and then tag the appropriate directories that contain the files we > modify with svn:external. These latter svn:external properties > would name the individual files we modify and point to the modified > version that we could keep in our repository. My concern is we are > "overloading" the files in the MW repository with files in our > repository and I am not sure subversion allows that. > There is a whole section in the svn book about this... http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.vendorbr BOb
RE: can I checkout only a revision files ?
> [Please do not top-post on this list, add / insert your response in > line] > > > -Original Message- > > From: Cooke, Mark [mailto:mark.co...@siemens.com] > > Sent: mercoledì 20 ottobre 2010 15.43 > > To: Andrea Antonio Maleci; Andy Levy > > Cc: users@subversion.apache.org > > Subject: RE: can I checkout only a revision files ? > > > > [Please do not top-post on this list, add / insert your response > in > > line] > > > > > -Original Message- > > > From: Andy Levy [mailto:andy.l...@gmail.com] > > > Sent: mercoledì 20 ottobre 2010 15.25 > > > To: Andrea Antonio Maleci > > > Cc: users@subversion.apache.org > > > Subject: Re: can I checkout only a revision files ? > > > > > > On Wed, Oct 20, 2010 at 09:17, Andrea Antonio Maleci > > > wrote: > > > > Is it possible to checkout only files (not patch, but > > > > entire files) from a specific revision ? > > > > > > Yes, use the --revision option for svn co. > > > > > > -Original Message- > > > From: Andrea Antonio Maleci [mailto:a.mal...@iwbank.it] > > > Sent: 20 October 2010 14:34 > > > To: 'Andy Levy' > > > Cc: users@subversion.apache.org > > > Subject: RE: can I checkout only a revision files ? > > > > > > It retrieves entire repository at specified revision, not > > > only the modified one... > > > > > That is the way subversion works. A revision number identifies a > state > > of the complete repository and includes all files / folders / > metadata > > etc. > > > > So, are you asking for only the files changed from the previous > > revision? > > Yes, I need only last changes, but entire files, not only diffs. > > > > > If so, why would you want that? Subversion only sends diffs > between > > client and server, so that is already efficient. > > It seems, from your answer, that I need to write a script, getting > output from svn log e requiring to svn last revision of changed > files. > > > > > If you want a list of the changes you can use the 'log' command. > > Remember that metadata can also change in a revision, not just > > files/folders. > > > > I am not aware that you can ask subversion to give you a working > copy > > only containing the files updated by a particular rev but I fail > to see > > how that would be useful... > > If you version and commit your classes, you need to get only > changed one to patch you application server. > That's why I need last committed files. > > > > > If that does not help, try rephrasing your question and/or > providing > > more background. My NAnt build scripts have a task that will create a "delta" of the changed deployables to create a hotfix for example. Just pulling out the changed stuff from svn wouldn't work anyway... since new binaries need to be built most of the time. BOb
RE: AW: German console output
> Guten Tag Mark Phippard, > am Donnerstag, 21. Oktober 2010 um 14:53 schrieben Sie: > > > It is a server distribution. Apache and ViewVC are not useless, > they > > are critical parts of a functioning server distribution. > > Only for those who don't already run Apache and don't want to use > the > stand alone server Subversion provides. And why is ViewVC preferred > over WebSVN, for example? I already run Apache, prefer WebSVN and a > setup where Subversion runs it's own server, or in my case two of > them. > > The point is, that people like me, or maybe just me at all ;-), > would > really appreciate an (semi-?)official download source where I can > just > download win32 binaries with all parts of Subversion, without > overhead > like Apache and ViewVC. > Collabnet's server install does have that. Just tell it not to install Apache. Is it DL size you are worried about? BOb
RE: AW: German console output
> 2010/10/21 Thorsten Schöning : > > Guten Tag Mark Phippard, > > am Donnerstag, 21. Oktober 2010 um 16:50 schrieben Sie: > > > >> We have no plans to support svnserve in CollabNet Subversion > Edge. > >> This is clearly listed in the posted information for the > product. > > > > Edge was just an example why I thought that download size didn't > > matter in your decision to not provide e.g. BDB etc. I don't use > edge, > > what I need, and thought you don't provide anymore, is something > > like "CollabNet Subversion Server and Client v1.6.13 (for > Windows)". > > I assume you have since found that download. It is still provided > and > updated with new releases. No.. where is it? I only see the Edge builds and the Command-line only build. Where is the server and client build? I am looking here: http://www.open.collab.net/downloads/subversion/ BOb
RE: Subversion 1.6.13 Released
> Sorry... Did I miss something? I see, CollabNet only providing > "bare client" > and "big pack". > If I need Subversion without Apache, should I look elsewhere? I > already have > Apache installation, which isn't easy to maintain. > And I don't want to screw it any further installing yet another > all-in-one > monstrocity. (Been there, done that mistake in the past) > > Erm... actually, forget that. I don't have account and don't see > the need for > registration just to be able to download one file. They still have what they had before. It does have Apache but you can disable it on the installer and it won't be installed. http://www.open.collab.net/downloads/subversion/svn1.5.html BOb
RE: mergeinfo not inherrited when I thought it should
> 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: Moving repository across servers : storage format problem
> I am trying to move a Subversion repository from one server > (running Windows > XP Professional SP3) to another (running Linux Debian 5 Lenny) > > The first server (on Windows) actually has Subversion installed > through a > VisualSVN GUI interface. > The second server has Subversion version 1.5.1 installed from > Debian packet > (as it is the latest stable version provided by Debian). > > I first tried to just copy the directory from the first computer to > the > second one, and check if it works. > But unfortunately, when trying to checkout the repository content, > I got the > following error message : > > "Format de stockage attendu entre '1' et '3' ; format trouvé '4'" > > (so in English, something like "Expected storage format between '1' > and '3', > found format '4'") > > Seeing that, I completely deleted the repository that I just > copied, and I > tried again, creating a new empty repository and moving using > "svnadmin > dump" on the first computer, and "svnadmin load" on the second one. Can you run svnadmin --version in the same pwd that you did the load to see what version of svnadmin you are running. BOb > > But, more surprisingly, when trying to checkout, I still get this > very same > error message !!!??? > > So I ask the question : > How can I move repositories between computers running different OS, > different versions of Subversion and different repository formats ? > > Is there any mean to convert a repository from one format to > another ? > > And also : > What are the actual formats identified by the numbers 1, 2, 3, 4 > (and maybe > 5, 6, etc) ?? > > Best regards, > > Gingko >
Usage discrepancies between two relatively identical systems
Ok admittedly, this might be a server configuration issue instead of specifically SVN, but I can't say for sure. I have a two different client machines, both updating from the same source repo. Both machines use the same version of SVN (1.4.2), the same kernel, and the same sudoers configuration. I try to run "sudo -u apache -H svn list https://domain.com/repos/myrepo";. One machine will auth just fine, while the other gives me the "Error validating server certificate" error. The cert is indeed invalid. However, the problem is that I can hit 'p' to accept the certificantly permanently, but yet, SVN doesn't remember the certificate or my acceptance of it. I'm not sure, but it seems that one machine will use the user's home directory SVN configuration properly while the other will not. For instance, the one that auths properly will grab the password from the /auth/svn.simple file and process the auth. The one that does not work properly will attempt to use `apache` as the user with no stored password. I've looked into the user .subversion directories on both machines, and things match up there. I'm stumped. Bob
Usage discrepancies between two relatively identical systems
Ok admittedly, this might be a server configuration issue instead of specifically SVN, but I can't say for sure. I have a two different client machines, both updating from the same source repo. Both machines use the same version of SVN (1.4.2), the same kernel, and the same sudoers configuration. I try to run "sudo -u apache -H svn list https://domain.com/repos/myrepo";. One machine will auth just fine, while the other gives me the "Error validating server certificate" error. The cert is indeed invalid. However, the problem is that I can hit 'p' to accept the certificantly permanently, but yet, SVN doesn't remember the certificate or my acceptance of it. I'm not sure, but it seems that one machine will use the user's home directory SVN configuration properly while the other will not. For instance, the one that auths properly will grab the password from the /auth/svn.simple file and process the auth. The one that does not work properly will attempt to use `apache` as the user with no stored password. I've looked into the user .subversion directories on both machines, and things match up there. I'm stumped. Bob
RE: svnserve : anonymous access not working
> I have a problem with svnserve : > > I want to configure it for allowing anonymous users to read it, but > this > don't work : > if I checkout (using TortoiseSVN), I am always asked to supply my > password. > > If I do it, the checkout works fine. > > Otherwise I cannot checkout. > > And if I click "OK" (in the TortoiseSVN authentication dialog) > without > giving any authentication (leaving all fields empty), I get the > following > message : > >SASL(-1): generic failure: Unable to find a callback: 2 > > svnserve (from Subversion 1.6.12) runs on a Linux server with > Debian lenny > 5.0 (64 bit edition). > > The "svnserve.conf" file for that repository contains the following > : > --- > - > [general] > anon-access = read > auth-access = write > realm = Référentiel Pouchin TV Mod > > [sasl] > use-sasl = true > min-encryption = 128 > max-encryption = 256 > --- > - > > For SASL, I have also a "svn.conf" file in the "/etc/" directory, > containing > the > following : > --- > - > pwcheck_method: auxprop > auxprop_plugin: sasldb > sasldb_path: /var/lib/svn/sasldb > mech_list: DIGEST-MD5 > --- > - > > Note that there is also an Apache access, running concurrently, > which works > fine for anonymous reading. But I also want this anonymous access > on > svnserve. > > svnserve is configured for logging all accesses, but the log > doesn't record > anything during theses failing anonymous accesses. > > svnserve is launched through the "inetd.conf" file, and the > corresponding > line is : > > svn stream tcp nowait > www-data > /usr/bin/svnserve svnserve -i --log-file /var/log/svnserve.log > -r > /var/lib/svn > > I don't understand why it doesn't work. > > Isn't it enough to set "anon-access = read" for allowing anonymous > reading > access ? Are you using path based authorization too? BOb
RE: Managing users
> I'm trying to solve a simple problem but can't find how in the svn- > book. > I need to manage my users in groups, actually teams, I need only > team > members to have read/write access to a set of projects and the rest > of > the organization only read access. > > My subversion authenticates users with a ldap server, so I need all > users > be part of a basic group that can read every project in the > versionning > repository and to group together some users and grant them write > access > to a selected set of projects. REally? Did you read the section on path-based authorization. It explains how to do exactly what you are asking about. http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.pathbasedauthz BOb
RE: svnserve : anonymous access not working
> -Original Message- > From: Gingko [mailto:from_tig...@nospam.homelinux.org] > Sent: Wednesday, November 17, 2010 1:27 PM > To: Subversion User List > Subject: Re: svnserve : anonymous access not working > > > - Original Message - > > From: "Bob Archer" > > To: "Gingko" ; "Subversion User > List" > > > > Sent: Wednesday, November 17, 2010 3:40 PM > > Subject: RE: svnserve : anonymous access not working > > > > > > I have a problem with svnserve : > > > > > > [..] > > > > > > Isn't it enough to set "anon-access = read" for allowing > anonymous > > > reading > > > access ? > > > > Are you using path based authorization too? > > > > BOb > > > I'm sorry, but I'm not sure to understand you very well ... > > What do you mean, exactly ? > > Gingko Did you set up an authz file where you specify what users can access certain paths? BOb
Upgrade OS/400 from V5R4 to V7R1
Hi... Any issues with Subversion jumping from release V5R4 to V7R1 of the iSeries OS/400? Thanks... Bob Robert Nason American Board of Pediatrics, Information Technology 111 Silver Cedar Court Chapel Hill, NC, 27514-1513 (919) 918.7107 Ext. 121 "Some people spend an entire lifetime wondering if they made a difference in the world. But the U.S. ARMED FORCESS don't have that problem." Ronald Reagan
RE: question about *.merge-right.r*
> I have a branch of trunk that I'm doing some work it. Someone > committed changes to ^/trunk that I wanted, so I ran "svn merge > ^/trunk" in a wc of my branch. > > One of the files had a conflict, and I postponed resolution. I > opened > the myfile.merge-left.r* and found the old version of the file. I > opened myfile.working and found what is currently in my branch. > > But when I opened myfile.merge-right.r*, the contents didn't match > any > version of the file I can find. None of the myfile.* files match > what > is in ^/trunk. I thought the myfile.merge-right.* file was supposed > to > be a copy of the file from ^/trunk. > > Can someone help me understand this? What gets put in the merge- > right file? I expect it is your BASE version. Here is the info from the book: For every conflicted file, Subversion places three extra unversioned files in your working copy: filename.mine This is your file as it existed in your working copy before you updated your working copy—that is, without conflict markers. This file has only your latest changes in it. (If Subversion considers the file to be unmergeable, the .mine file isn't created, since it would be identical to the working file.) filename.rOLDREV This is the file that was the BASE revision before you updated your working copy. That is, the file that you checked out before you made your latest edits. filename.rNEWREV This is the file that your Subversion client just received from the server when you updated your working copy. This file corresponds to the HEAD revision of the repository. Here OLDREV is the revision number of the file in your .svn directory, and NEWREV is the revision number of the repository HEAD. BOb
RE: Unable to lock error: what is going on here?
> $ svn update > svn: Unable to lock 'utscmd' > > $ svn propget svn:ignore > utspkg_src > utscmd > utslib > utsbin > utstool > > utscmd is a subdirectory of the current working directory. It is > included in svn:ignore. Why is svn even trying to lock this > directory? > > The sequence of events here is that the project was checked out and > then > its build command run. The build command created a number of > directories, which have been added to svn:ignore so as not to > figure in > svn at all. > > What am I failing to understand here? Are you sure utscmd is not already versioned. Ignores only works on non-versioned files. BOb
RE: Unable to lock error: what is going on here?
> On 12/02/2010 08:39 AM, Bob Archer wrote: > >> $ svn update > >> svn: Unable to lock 'utscmd' > >> > >> $ svn propget svn:ignore > >> utspkg_src > >> utscmd > >> utslib > >> utsbin > >> utstool > >> > >> utscmd is a subdirectory of the current working directory. It > is > >> included in svn:ignore. Why is svn even trying to lock this > >> directory? > >> > >> The sequence of events here is that the project was checked out > and > >> then > >> its build command run. The build command created a number of > >> directories, which have been added to svn:ignore so as not to > >> figure in > >> svn at all. > >> > >> What am I failing to understand here? > > > > Are you sure utscmd is not already versioned. Ignores only works > on non-versioned files. > > > > BOb > > > > > > > Yes, that was the problem. The directory was already versioned and > it > shouldn't have been. The build process then came along and > destroyed it > (including its .svn subdirectory) and made a new one. > > However, I still don't understand why svn update is designed to > fail if > unversioned directories are found below it. Couldn't they just be > ignored? try... svn up --force BOb
RE: Problem with svn merge --reintegrate
> Hello World, > > I have implemented a feature into our product. To not break things > for the other developers, I used a feature branch as described in > the svn book. Now my implementation is complete, so I want to merge > my branch back to trunk. In a fully updated working copy of the > trunk (with no locales changes), I do: > > J:\QUARTIS\_dev>svn merge --reintegrate > http://srv2.metromec.local:8080/svn/QUARTIS/shelves/ATs/PROGPersist > ence/_dev --dry-run > > which gives me: > > Reintegrate can only be used if revisions 13561 through 15007 were > previously > merged from http://srv2.metromec.local:8080/svn/QUARTIS/trunk/_dev > to the > reintegrate source, but this is not the case: > shelves/ATs/PROGPersistence/_dev/src/include/FilterLibrary/Test/Tes > tDataGenerator > Missing ranges: > /trunk/_dev/src/include/FilterLibrary/Test/TestDataGenerator:13561- > 15003 > shelves/ATs/PROGPersistence/_dev/src/include/FilterLibrary/Test/Tes > tFilterLibrary.res > Missing ranges: > /trunk/_dev/src/include/FilterLibrary/Test/TestFilterLibrary.res:13 > 561-15003 > shelves/ATs/PROGPersistence/_dev/src/include/FilterLibrary/Test/Tes > tMeasureElementDataInOut.pas > Missing ranges: > /trunk/_dev/src/include/FilterLibrary/Test/TestMeasureElementDataIn > Out.pas:13561-15003 > shelves/ATs/PROGPersistence/_dev/src/include/FilterLibrary/Test/Tes > tMeasureElementGaussFIRFilter.pas > Missing ranges: > /trunk/_dev/src/include/FilterLibrary/Test/TestMeasureElementGaussF > IRFilter.pas:13561-15003 > shelves/ATs/PROGPersistence/_dev/src/include/FilterLibrary/Test/Tes > tMeasureElementReducePointsByDistanceFilter.pas > Missing ranges: > /trunk/_dev/src/include/FilterLibrary/Test/TestMeasureElementReduce > PointsByDistanceFilter.pas:13561-15003 > > The mentioned files and directories exist in the trunk (and seem to > have already existed before the branch was created), but are > missing on the branch. I have read in the mailing list archives > that a svn merge --record-only (or a corresponding change of the > svn:mergeinfo properties) could fix the problem, but how do I find > out which revisions are affected (e.g. in which revisions the files > and directories were lost)? > Do you have a sparse checkout by any chance? Are you merging in at the same folder level from where you branched? BOb
RE: SVN Version upgrade.
> > From: Gavin Beau Baumanis [mailto:b...@palcare.com.au] > > > > For our production repositories we're using 1.5.1 > > > > My question is - is there an appropriate version to upgrade to? > > We're tossing up between; > > > > Update to the latest 1.5.x > > Update to 1.6.x > > Or simply wait it out - for 1.7 > > > > Is there a "suggested" upgrade path? > > Basically, whatever you want is fine. You should upgrade to at > least a > newer version of 1.5, for bugfixes and so forth. And maybe you > care about > new features of 1.6. I find the performance improvement in 1.6 to > be quite > noticeable. > > On the server, there's no need to dump/load your repository, if you > simply > start using 1.6 server process, it's compatible. That being said - > All the > stuff that was written in repo by 1.5 will continue having 1.5 > performance, > while new stuff will be written in 1.6 format and faster. If you > want > optimal performance, and can afford to extend the downtime, then > doing a > dump/load to upgrade your repository might possibly enhance > performance. Of course you can run svnadmin upgrade to bring the repository to version 1.6. If you don't it will keep storing stuff in the 1.5 format and you will lose many of the advantages of 1.6. BOb
RE: Problem with svn merge --reintegrate
> > > Hello World, > > > > > > I have implemented a feature into our product. To not break > things > > > for the other developers, I used a feature branch as described > in > > > the svn book. Now my implementation is complete, so I want to > merge > > > my branch back to trunk. In a fully updated working copy of the > > > trunk (with no locales changes), I do: > > > > > > J:\QUARTIS\_dev>svn merge --reintegrate > > > > http://srv2.metromec.local:8080/svn/QUARTIS/shelves/ATs/PROGPersist > > > ence/_dev --dry-run > > > > > > which gives me: > > > > > > Reintegrate can only be used if revisions 13561 through 15007 > were > > > previously > > > merged from > http://srv2.metromec.local:8080/svn/QUARTIS/trunk/_dev > > > to the > > > reintegrate source, but this is not the case: > > > > shelves/ATs/PROGPersistence/_dev/src/include/FilterLibrary/Test/Tes > > > tDataGenerator > > > Missing ranges: > > > > /trunk/_dev/src/include/FilterLibrary/Test/TestDataGenerator:13561- > > > 15003 > > > > shelves/ATs/PROGPersistence/_dev/src/include/FilterLibrary/Test/Tes > > > tFilterLibrary.res > > > Missing ranges: > > > > /trunk/_dev/src/include/FilterLibrary/Test/TestFilterLibrary.res:13 > > > 561-15003 > > > > shelves/ATs/PROGPersistence/_dev/src/include/FilterLibrary/Test/Tes > > > tMeasureElementDataInOut.pas > > > Missing ranges: > > > > /trunk/_dev/src/include/FilterLibrary/Test/TestMeasureElementDataIn > > > Out.pas:13561-15003 > > > > shelves/ATs/PROGPersistence/_dev/src/include/FilterLibrary/Test/Tes > > > tMeasureElementGaussFIRFilter.pas > > > Missing ranges: > > > > /trunk/_dev/src/include/FilterLibrary/Test/TestMeasureElementGaussF > > > IRFilter.pas:13561-15003 > > > > shelves/ATs/PROGPersistence/_dev/src/include/FilterLibrary/Test/Tes > > > tMeasureElementReducePointsByDistanceFilter.pas > > > Missing ranges: > > > > /trunk/_dev/src/include/FilterLibrary/Test/TestMeasureElementReduce > > > PointsByDistanceFilter.pas:13561-15003 > > > > > > The mentioned files and directories exist in the trunk (and > seem to > > > have already existed before the branch was created), but are > > > missing on the branch. I have read in the mailing list archives > > > that a svn merge --record-only (or a corresponding change of > the > > > svn:mergeinfo properties) could fix the problem, but how do I > find > > > out which revisions are affected (e.g. in which revisions the > files > > > and directories were lost)? > > > > > > > Do you have a sparse checkout by any chance? Are you merging > > in at the same folder level from where you branched? > > No, it's a normal checkout, and I was and am merging at the same > folder level (_dev) from where I branched. > > I noticed however that the mentioned files have been changed in > another branche and then were merged to trunk (within the given > range 13561-15003). Is this in some way helpful/important? Well... there you go. If there has been activity in the trunk since the branch was done, then you must merge trunk into branch before you can re-integrate back into trunk. Although, it seems strange that it would mention revision range that was prior to your branch being created. BOb
RE: tracking multiple "test" groups
From: Coleman, Brandon [mailto:brandon.cole...@gohastings.com] Sent: Tuesday, December 07, 2010 2:38 PM To: users@subversion.apache.org Subject: tracking multiple "test" groups I currently use SVN with Feature branches that are tested, merged to trunk, compiled and then sent to a small group of test production machines. If the code at the test machines works as planned for a test period then the compiled code is deployed to all production machines, and if a bug is found, the branch is removed from trunk and the binaries changed back to the old state. We would like to have two (possibly more) groups of test production machines with different sets of test code at each test group. What is the suggested way of keeping two sets of test code? My thought was to compile the branches I would like to go to a test group in their branch directory and just keep them updated and compiled with the latest branches committed to trunk, but I want to know from others experience if there is a better way. Brandon
RE: Archiving Projects (End-Of-Life)
> I'm wondering if there is a (de-facto) standard way of "end-of- > lifing" > projects in an SVN repository, or any suggestions for this from > other > users on this list ... > > With End-Of-Life I mean there will be no further maintenance on > that > project, no more development, no more releases or patches, no more > users. It's really dead. But sometimes one might want to take a > look > at the old code, check out its history, maybe even resurrect it, > ... > I would like to get those projects out of sight, so it's more clear > what the active projects are. (I'm not talking about > "obliterating", > to reclaim disk space or anything like that, quite the contrary: I > want to have them still available, just ... less visible). > > I know I could just "svn rm" them, but some of the "project owners" > feel a little bit uneasy about that. They consider it "probable" > that > they will need to take another look at them sometime in the future. > And as we all know, it's not so easy to find a deleted > file/directory/project again (to find out what the latest revision > was > in which the project still existed). > > My repository is currently structured as: > > trunk > \--project1 > \--project2 > \--... > branches > tags > > But I think the question is more or less the same if it's > structured > in the other standard way (projects/TTB). > > Currently I have two options in mind: > - Move the EOL'ed projects to a new directory "archive", a new > "root" > directory next to TTB. > - Move the EOL'ed projects to a tag (maybe also in an "archive" > subdirectory, under tags). If it ever needs to be resurrected, it > can > be easily copied from that tag. > > Thoughts? Other ideas? Pros and cons? > Two options I can think of.. one simple, one will need admin access... 1. Create a folder in your repository named (end of life) and move the project folder there. 2. Dump the repository, use dumpfilter and import it into an "end of life" repository, then RM it from your main repo. BOb
RE: alternative to CVS magic branches
> in CVSNT there's a feature called magic branches. Basically it > means that > if you branch from head (or any other branch) the all the files in > the > magic branch will continue to have all changes made in the future > until > the point where you change them. So if you have 20 files and you > change > only a small number of them you only have to merge changes to the > files > you modified, the others always have changes in the trunk. > Is the only option in Subversion to merge the trunk to the branch > regulary Yes, pretty much. BOb
RE: svn 1.4.2 to 1.4.9
> We are planning to upgarde Subversion from 1.4.2 to 1.4.9. But i > have a couple of questions regarding this. > 1)what are the changes in 1.4.9 from 1.4.2 in terms of release > notes? 1.4 is very out of date. That's probably why you can't find the release notes. You strongly should consider upgrading to 1.6.latest. > 2)The ove needs a dump and load of repository or does the existing > repository upgrade as soon as the server \ client on the system is > upgraded .. meaning new binary is used ?? When going from 1.4.x to 1.4.y there is no change to the repository format. So, just put in the new binary and away you go. If you do go up to 1.5 or 1.6 then you can either do a dump / load sequence (usually recommended) or you can run svnadmin upgrade. > > Thanks for the help! BOb
RE: ignored files
> The updated version of that page of documentation for the current > version of Subversion is: > > http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html > > Good to know, thanks. Unfortunately Google returned the 1.1 > version of the doc for my query. For different queries, I see the > documentation for other older versions of svn (1.4, 1.5), but I > don't see the docs for 1.6 or the nightly. > The nightly is basically for 1.6. http://svnbook.red-bean.com/nightly/en/svn-book.html BOb
RE: SVN BUG : Lines disappeared after update and check in
> I experienced the following behavior with SVN. The steps i did are > : > > 1- I made changes in a file > 2- updated the file > 3- Checked in the file after the merge succeeded > 4- In the resulting file 6 lines disappeared. > > Is it considered as a bug? > has anyone experienced such a behavior? > If it truly is losing lines that would be a bug. However, what were the merged in changes? Are you sure the merge during the update didn't remove lines? BOb
RE: Looking to hire Software Engineers to Help Develop Subversion
> On Tue, Dec 21, 2010 at 12:25 PM, David Weintraub > wrote: > On Tue, Dec 21, 2010 at 3:03 PM, Pablo Beltran > wrote: > > Hi, > > > > I have no doubt about those all features will be good for the > future of > > Subversion, from a technical point of view. > > > > On the other hand, the underlaying message scares me. The message > is clear: > > Apache can't drive the development process by itself and only > Wandisco can > > do it in the right way and in timing. > > > > And I think that this exceeds Subversion project and undermines > Apache's > > authority. > > > > Today is Wandisco and Subversion. Tomorrow could be Oracle or > Microsoft > > doing the same with other project. I would not like see Apache > become in a > > silly Software Factory. > > > > But of course, I have not enough knowledge about how Apache > internally works > > and perhaps I'm saying a very great stupidness. So, my apologizes > for that > > if that is the case. > > > > I am going to look at this a bit differently: Has IBM taken over > Linux? A majority of the changes in Linux are done by IBM paid > employees. IBM has its own goals and its own ideas about what they > want to do with Linux. > > However, I believe most people feel that Linux isn't an IBM project > despite the massive amount of work done by a single company. > Basically, IBM benefits from Linux, so they do a lot of code work, > sometimes working on areas that have been previously neglected. The > better Linux is, the more IBM can sell Linux solutions. > > Subversion has had a lot of problems since version 1.5 has come > out. > Basically, the merge/branch tracking isn't that great. In fact, > many > people prefer the 1.4 version which doesn't make any pretensions > about > tracking branching and merging. > > Meanwhile, many people feel Subversion is past its prime. Many open > source projects are moving from Subversion to Git. Actually, this > makes sense for open source projects, but it is beginning to affect > commercial applications. People are starting to push Git as a > commercial SCM package. > > I recently pointed out on another list that I might recommend a > piece > of software I don't think is as good as another piece of software > simply because the "inferior" product plays better with the other > software the company uses and because users are more familiar with > it. > > I might not like Git as a commercial version control system, but if > most developers are more familiar with Git than Subversion, and 3rd > party products start integrating with Git in better ways than they > integrate with Subversion, guess what I'm going to start to > recommend. > > So far, Subversion isn't being forked, and a fork would not be good > for WANdisco. They are heavily dependent upon people selecting > Subverson as a version control system. What they want to do is fix > some of the underlying issues Subversion has had for the last three > years and get the Subversion project to accept them. I can't see > any > reason why the Subversion project would reject them. After all, > Subversion was once run by CollabNet which had commercial interests > in > Subversion. Yet, no one complained about CollabNet "dominating" the > project. > > I hope that WANdisco is able to fix many of the issues that have > been > plaguing Subversion for years. I don't believe that those who are > leading Subversion have "failed", but that a private company > committing resources to an open source project can be a good thing. > Absolutely correct! > > Your analysis / explanation is much better than my own. Thank you. > > - David I also think this is good news and look forward to seeing the WANDisco contributions to the project. And if I had any more knowledge of the svn internals I might be applying for one of those positions. BOb
RE: changing the structure of code in public repo
> My former team member had put some code in a public repository > sometime back.Currently I am the sole team member now and need to > modify the code. > I am relatively new to subversion and version control systems in > general.. > > I can checkout the code using > svn checkout https://myproject.somepublicrepo.com/svn/trunk/ > > the source tree structure in repo is > svn/trunk/src/myproject/One.java > /Two.java > > I thought of changing the package structure of code as follows, > myproject/ > /build.xml > /src > /packageone/NewOne.java > /packagetwo/Two.java > /lib > /images > > How should I go about this? should I checkout into a work dir and > then > delete all of its contents ,then create the new code structure and > then commit ? > Or should I delete the directories from repo first? No, don't just delete then replace. Use the svn commands to do your refactoring. Basically the svn move command. Once you have done all your refactoring commit your changes. Have you read the free svn book? Specifically the "basic usage" chapter? BOb
RE: svnadmin create and not being method agnostic
> 2010/12/28 Thorsten Schöning > Guten Tag Philip Prindeville, > am Montag, 27. Dezember 2010 um 22:28 schrieben Sie: > > > In our case, we're setting up a secured source repository inside > > our network, for outside access (via port-forwarding on our > gateway). > In this scenario and if security is this important for you, then > why > not just use svnserve? > > I don't know what Philip's reasons are, but svnserve does have some > shortcomings that might make it unsuitable for sites that are > serious about security. The most obvious one is that it requires > passwords to be stored in cleartext in the repository passwd file > on the server. You can use SASL with svnserver and you can use svn+ssh to tunnel through ssh which I hear is pretty secure. > Another one is its lack of any logging or auditing > capabilities. v1.6 added logging to svnserve. > > On the other hand, when you start using Apache you've got a whole > 'nother pile of code that can have security holes in it...so it's > really a matter of which risk you're more concerned about. yep, 6 of one... BOb > -- > David Brodbeck > System Administrator, Linguistics > University of Washington
RE: svnadmin create and not being method agnostic
> I can also argue with the Principle of least astonishment: > > So say we've added a new svnadmin option --dont-create-svnserve- > config, > and we've made svnserve skip repositories which don't have an > svnserve.conf file within them (putting aside the still unsolved > problem > of what svnserve should do when run with a single global config > file). Well, the next complaint would be... that should be the default since if I run svnadmin create I don't "know" I need to use that option. It all comes back to, imnsho, people expect to be able to use complex software without spending even a small amount of time reading documentation and understanding how stuff works. Is there really that much overhead in deleting the binary and insuring the correct permissions are used on the repository folders to "keep the honest, honest?" After all, any one with root/administrator access is able to bypass anything you've done anyway. It rather see the devs working on 1.7 WC features like a real "branch" command, performance, etc, rather than adding a config option that nobody will use. Also, if you want a more "secure" version of subversion package up your own binaries that don't include svnserve... let the svn dev's work on the stuff that we can't do with 3 or 4 lines of a batch/command file. BOb
RE: svnadmin create and not being method agnostic
> Windows (if that can be considered "secure" in the first > place), > that would also be interesting. But I'm afraid I wouldn't be able > to help with that. Why all the hate? :) Suffice to say, windows servers (these days) are only as secure as the admin makes it. I guess that applies to *Nix servers too. BOb
RE: svnadmin create and not being method agnostic
> > svnadmin create .\repository > > svnserve -r . > > > > and a repository is created and served via svnserve. With the > above > > defaults, a third step is required, which can get tedious. I'd > propose > > enabling svnserve by default, and it can then be disabled if > required. This > > also maintains the ease of creating test scripts to try and > reproduce > > issues. > > It's *too* easy. Since the default svnserve.conf is very > permissive, > and because default svnserve is on an unprivileged port so any user > can serve anyone else's "readable" repository to outside access, > without the original author's knowledge or explicit consent. The > default permissions of "svnadmin create" and "svnadmin hotcopy" are > much too permissive, and the concatenation of separate "the admin > should set these if they want" options creates a quite noticeable > security risk. Yes, well aren't you still only keeping the honest people honest? Since svn is open source anyone can edit the code so the check of servers.conf is a no-op and it serves anyway. Why are you making your repository "readable" in the first place? BOb
RE: Merging in Subversion
> > . Is there any best way to merge files in SVN or you need to > > incorporate any strong merging tool? > > Text files are handled well by SVN's builtin merging capabilities. > For other > files, I don't know how to merge them. In practice, I consider > anything > non-textual as non-mergable, too. This means that merging requires > manual aid > (unless the base version of both branches is equal, in that case > SVN does the > job automatically) and that the "needs-lock" property is always > set. In our shop the policy is that if a fix is made in a version to a binary file, that same fix is applied to higher versions. This is usually an issue with reports since we use crystal the .rpt files are binary. It seems to work for us but may not work for others. If only every file could be textual... ;) BOb
RE: externals behavior with tags
> > Option 2 is supported, and in fact is the recommended method. > > > > See: > > http://svnbook.red-bean.com/nightly/en/svn- > book.html#svn.advanced.externals > > And if you want the externals references on your trunk to float > with the > trunk of the referenced item during development, one approach is to > always make an intermediate branch where you make these and any > other > needed changes before making the tag. Or, just make the changes on your working copy and create the tag from your working copy. BOb
RE: externals behavior with tags
> Thanks for the link. I knew the -rREV method was supported I just > feel that doing that for every externally referenced file is a pain > and one more thing to keep track of. Oh well. > > Is there a way to search for all instances of an externally ref > file in the entire repo? I think a "where used" type function is > what im looking for. > There is also a tool called svncopy that will peg the externals for you. http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svncopy/svncopy.README BOb
RE: Copy with externals, then commit fails
> I tried to create a new branch of a trunk that had some > svn:externals definition. > In particular, it pointed to a file. > > I.e. > /somewhere/a.txt@4 a.txt > > I used > svn copy svn://server/trunk branch > And the output from that was the usual stuff including > E a.txt (indicating an externals file). > > svn stat had the following output: > +X a.txt > Of course, the plus means "with history". > > After this, I could not do a commit. The commit failed with a > message: > svn: File not found: revision 4, path '/trunk/a.txt' > > My suspicion is that due to the fact that the file has history > associated > with it, the commit tries to commit a file that it shouldn't be > committing. > Besides, I didn't want to add a.txt to my branch, I still wanted it > to come > from the original externals definition. Is it a bug that svn copy > adds > history info to an external file? File externals require that the file being pointed to is in the same working copy as the external of it. From the docs: "While directory externals can place the external directory at any depth, and any missing intermediate directories will be created, file externals must be placed into a working copy that is already checked out." BOb
RE: Checkout really slow in Windows with lots of files in one directory
> On Wed, Feb 2, 2011 at 7:41 AM, Geoff Rowell > wrote: > > On Wed, Feb 2, 2011 at 4:09 AM, Nick > wrote: > >> On Tue, 2011-02-01 at 13:00 -0500, Mark Phippard wrote: > >> > >> On Wed, Jan 26, 2011 at 9:28 AM, Neil Bird > wrote: > >> > >>> We have a graphics-oriented code-base that's auto-generated > and has >5000 > >>> source files in one directory. While I can check this out OK > on Linux, > >>> we're seeing an unusable slow-down on Windows XP (NTFS), both > using > >>> Tortoise > >>> directly, and as a test on Linux with the Windows drive mapped > over CIFS. > >> > >> I created a folder with 5001 files in it ... maybe that is not > enough? > >> I just used small simple text files as I was only checking for > the > >> general problem in managing the temp files and the WC metadata. > >> > >> Upon checkout (using 1.6.15 command line client) I did not > notice any > >> slowdown. Windows checked out via HTTP across internet in about > 49 > >> seconds as opposed to 33 from my Mac (which is a faster system). > The > >> main thing is checkout did not seem to slow down. > >> > >> I did a similar test, using 5100 files in a single directory. > Each file > >> contained only the content "file " where was the number > of the file > >> (so tiny files). My linux system took 17 seconds, while Windows > took a bit > >> less than 2 min (but Windows is virtualized while linux is on > the > >> hardware). I also did not notice a slow-down as the checkout > proceeded. > >> Both systems used 1.6.15 and accessed the repo via https. > >> > >> I did, however, notice that the time to *add* the files (done > via svn add > >> *.txt) seemed to progressively slow down. But this was only > observed by > >> watching the files in the console as they were being added (it > was > >> relatively easy to see the rate because the each file name had a > linear > >> number at the end). I don't have any timings to back this up, > though I'll > >> collect some if anyone's interested. > >> > > I don't know why, but I believe the key thing here is working > with > > *binary* files. > > > > I noticed the same problem with a massive (10K+) amount of audio > > snippets in a single directory. > > I was thinking that this was a case where the > reading/parsing/writing > of our large entries file was causing a slowdown and moving to > SQLite > was going to bring performance gains. Clearly that is not the case > as > trunk is much slower. > > If I get another batch of free time I will try it with a lot of > small PNG's. Running Working Copies on RAM drives in Windows makes it fly like the devil. For anyone inclined to give it a try. Of course, you need some free RAM to be able to do it. I set up a 2GB RAM drive to try it. I was really trying to improve Visual Studio perf though, and not svn... so I don't use it any more. But, I did notice that all svn stuff was much much faster. I can't recall the software I tried. BOb
RE: Error on Post Commit Hook.BAT
> On 2/1/2011 11:36 PM, Waseem Bokhari wrote: > I am not using any email program But Only using my SMTP SERVER > > E:\Repositories\WSBokhari\hooks\send_message.exe %MESSAGE_FILE% > %server% %to% %from% %subj% %auth% > > > Then how would I mention this? > > > > You need to find a program that contacts your SMTP server from the > Windows command line prompt and sends a message to the server. You > may have one already installed on your machine; if you are defining > a repository for a group of developers you will also need to ensure > that it is installed (or at least accessible on the search path) on > every developer's machine. > > My Subversion installation does not send E-mail to developers and > so I do not know of any programs that send mail to an SMTP server > from a Windows command line prompt. Perhaps someone else on the > list will know. I can't help you further. > > -- > David Chapman dcchap...@acm.org > Chapman Consulting -- San Jose, CA On a Windows server with the SMTP server running you can just drop the email file into the mailroot\pickup folder and the email will be sent automatically. This is probably easier that finding some program that uses the SMTP protocol... tHis assumes the credentials running your batch has permissions to the pickup folder on the SMTP server of course. BOb
RE: File already exists Error with Subversion 1.6.12
> Hello, > we have following error with importing dump file fom svnimporter of > polarion: > > codebeamer@af4hh087:/var/home/tmp_adm> svnadmin load > /apps/codebeamer/CB-5.5.1-b02/repository/svn/ARUEHISTORIE/ < > /var/home/tmp_adm/full_dump_20110128_102420.txt.bin > <<< Started new transaction, based on original revision 1 > svnadmin: File already exists: filesystem '/apps/codebeamer/CB- > 5.5.1-b02/repository/svn/ARUEHISTORIE/db', transaction '2-11', path > 'trunk' > * adding path : trunk .. > > I read many issues in the internet concerning this. Do you know > this error and is there a solution for this? By the way, there's no > file or directory db inside the dump. > > Best Regards > Ingo Carstens Two things... 1. You did create a repository with svnadmin first. Load will not create a repository. You are loading into an empty repository? 2. Try the command without the trailing slash on the repository path... all the example I see don't use it, and I also don't put it when I have done loads. BOb
RE: Importing a git repos to subversion
> At work we use Subversion, and one of the developers have been > developing a project for a while in an external git repos (he > started > the project when he was a consultant). > > Is there any way to import this into a new svn repos keeping > history and > everything? > I think you can use git-svn to push a git repo to an svn repo. BOb
RE: Request for comments on our vendor library structure
> We are developing a fairly large application that uses open source > libraries. We have one svn repo per application. Currently, the > open source libraries are all stored with the application. This is > a bad idea because the working copy and repo are now very large. > Also, every branch gets a copy of all the open source code. > > So I propose to move the open source libraries into a separate > repository. We can then reference that code either using externals > or, more likely, environment variables in the build files. I prefer > the latter because then the open source code will never appear in > the project's working copy and we can easily exclude it from > branches if it is not required. > > So how should I structure the open source (vendor) library repo? I > was thinking of the following: > > OpenSourceLibs >| >| Boost >|| tags >|| trunk >| >| wxWidgets >|| tags >|| trunk > etc. > > That way, I can tag each library individually. > > We then check out OpenSourceLibs beside the application's working > copy, and specify in the makefiles which libraries to use by > referencing the tags. > > My concern is that each developer must correctly checkout and > maintain his/her OpenSourceLibs working copy. It would be best to > do this as a sparse working copy so they only get what is needed, > but that is not easy for the developer to do as I have a repo of > projects of tags i.e. several layers for him to manage. Or they > could just checkout and update the entire OpenSourceLibs folder, > but that would be very large. > > Would anyone like to suggest how best to handle this please? > Many people like to make their projects atomic. That is, when you check out the project folder you have everything you need to build it, including build tools and compilers. Some scale that back and require that the compilers be on the machine... some ever further requiring that the compilers and build tools be on the machine. You want to go one step further and require that common libs/code be on the machine. There is really no right or wrong way... it is just what works best for you. Personally, hard drive space is cheap. I would rather have all the dependencies for each project in my working copy. Sure, store it once in the repository and use externals in your projects. Once again, this is all preference, and I just gave you mine. Only you can decide what is right for you. BOb
RE: svnadmin create complains about subrepositories
> I just recently upgraded to svn 1.6.12 and had to realize > > svnadmin create > > wont let me create Repositories inside directories where have > already > repositories been created. > > Why is that a "feature" and can you please add an --force switch to > still being able to create Repositories within the path of another? I guess my question would be "why do you want to do that"... and I would also say DON'T do that. Bob
RE: svnadmin create complains about subrepositories
> > On Feb 10, 2011, at 09:59, Stefan Sperling wrote: > > > > >> and can you please add an --force switch to > > >> still being able to create Repositories within the path of > another? > > > > > > That's a reasonable request, I think. Not a usual use case but > why > > > not? > > > > Really? What possible reason could exist for doing this? :) > > > > We are using Redmine as a projectmanagement Tool and there projects > can > have subprojects. This hierarchy we also want in the file system > level > so we can see from the url of the repos which category it belongs > to. I expect that this all happens inside the repository. A repository's contents can have whatever folder layout you want. However, the repositories themselves on the server each need to be peers. You can't nest repos nor should you need to. > > @Stefan: I have no idea what the former Version was, but I upgraded > from debian Lenny to squeeze so it was probably 1.5.1. > > Would it hurt to add a force switch? I mean its at the users risk > isnt > it? > Yes, it would hurt. This is like saying, I want to create a mySQL database inside my current mySQL database... why can't I do that? BOb
RE: svnadmin create complains about subrepositories
> On Thursday 10 February 2011, Stefan Sperling wrote: > > On Thu, Feb 10, 2011 at 07:02:18PM +0100, Fabian Richter wrote: > > > Am Thu, 10 Feb 2011 11:24:09 -0600 > > > schrieb Ryan Schmidt : > > > > On Feb 10, 2011, at 09:59, Stefan Sperling wrote: > > > > >> and can you please add an --force switch to > > > > >> still being able to create Repositories within the path of > another? > > > > > > > > > > That's a reasonable request, I think. Not a usual use case > but why > > > > > not? > > > > > > > > Really? What possible reason could exist for doing this? :) > > > > I have no idea, to be honest. But then again I'm not going to > guess. > > Maybe someone can present a good use case for this? Dunno. > > The only reason I'm aware of is that you want to make browsing > easier when you > have multiple repositories, as there is otherwise no way to do > that. The idea > is that you have a parent FS-dir that contains the parent repo. The > parent > repo FS-contains the child repos. Further, it has repo-directories > for each > child repository, too. Since SVN tries to walk the FS-path as far > as possible > for locating the repository. Therefore, a "svn ls parent" will show > the > repo-content of the parent's root but a "svn ls parent/child-x" > will not show > the repo-content of the parent's child-x subdir but show the root > of the > parent/child-x repository. > > In that light, I support the suggested "--force" option for people > that > really, really need it. If I have a project that has child sub-project I really really want them to be in the same repository. Actually, I put all my projects in the same repository so I can browser them in "some" repository browser like T-SVN of ViewVC. We have multiple repositories but they are for different product groups that work on projects that have no relationship to each other what so ever. Even those could be in the same repository but seeing how path based auth slows things down it seemed to make more sense to give each product group their own repo. BOb
RE: svnadmin create complains about subrepositories
> Am Thu, 10 Feb 2011 14:27:17 -0600 > schrieb Ryan Schmidt : > > > > > $ svnadmin create repo1 > > $ svnadmin create repo1/repo2 > > svnadmin: 'repo1/repo2' is a subdirectory of an existing > repository > > rooted at 'repo1' $ svnadmin create repo2 $ mv repo2 repo1 $ ls > repo1 > > README.txt db hooks repo2 > > confformat locks > > $ > > > > Et voilà, you have repo2's directory inside repo1's directory. > > > > Yes, this is the only way I would be able to do it, though its a > pretty nasty thing if you have scripts, creating your repositories > on the fly. > > Again because noone really understood the problem: I need nested > repositories because without I can not grant granular access > rights. > > Eg: I have a redmine project called x and a repository called x. I > have access to that repos and some other dudes. Now I need to > create a new subproject that belongs virtually to x called z. To > maintain this connection I want it to be visible within redmine as > a subproject to x. > I also want to grant access to that project to different people > than I granted to x. Still I need to maintain the connection to x > and hence the need of creating subrepositories... > > Funny noone of you mentioned one damn reason why the force option > would be bad. You just said "Its not like we want it to be" but > apart from that, your argumentation is not present. Have you brought this up on the redmine support or users list? It seems to me that more than one person would be using nested projects in RedMine and since nested repositories in svn is an anti-pattern I expect there is a better way to do this... or you are not understanding RedMine's sub-projects... or there is a deficiency in redminds security that doesn't allow you to set different permissions to a nested subprojects in a single repository. Perhaps redmine doesn't require the nested projects to actually point to nested repositories? BOb
RE: Subversion Permissions Question.
> On Feb 11, 3:21 am, Thorsten Schöning > wrote: > > Guten Tag MonicaS, > > am Donnerstag, 10. Februar 2011 um 17:33 schrieben Sie: > > > > > We are using an old > > > version that we are going to upgrade as soon as we are > confident that > > > we understand the current configuration and setup. > > > > It should be possible to upgrade to a newer version even without > > understanding, because unless you dump and load your > repositories, the > > old format and configuration is kept and should just work. You > would > > just loose benefits of newer FSFS-versions or stuff like that, > but can > > dump and load whenever you like. > > It is good to know that. I'm going to try to do it as soon as the > team > is ready. > > > > > The authz file contains the following three lines. If I > understood > > > correctly, svnadmin will have rw permissions to the whole > repository > > > and the rest of the users will have read-only access. > > > But all users are able to 'checkout' and 'submit' files. So > what are > > > these permissions really doing? > > > [/] > > > svnadmin = rw > > > * = r > > > > Which users are in the group svadmin? If all, then all should be > able > > to commit etc. > > only one user belong to the svnadmin group. Did you verify that subversion is actually configured to use the authz file? Just because it exists doesn't mean it is being used. > > > > > > > I see the files svnserve.conf and authz on different > subdirectories. > > > Shouldn't these files be only in the main or initial folders of > the > > > repository? > > > > Per default those files should be in the conf-directory of the > > repository, but the location of authz can be configured in > > svnserve.conf. > > > > ### Uncomment the line below to use the default authorization > file. > > authz-db = authz > > > > vs. > > > > ### Uncomment the line below to use the default authorization > file. > > authz-db = ../../foo/bar/authz > > > > OK, so only the repositories have the sub-directories db, conf, > dav, > format, hooks and locks. > > If this is true, this installation looks like only one repository > but > I really have 506 repositories. I have repositories under > repositories. That's not good. But are you sure about that. Where are you "seeing" 506 repositories? Perhaps you just have 506 projects in a single repository. BOb
RE: What is a "baton" from subversion sources?
> I'm learning subversion API right now and examining it's source > code and > examples. It's a lot of things in subversion source code that is > called > a "baton". For example, svn_cmdline_create_auth_baton() create > "auth > baton", and callbacks takes callback function pointer and, again, > batons. I never heard of a term "baton" related to the programming. > That > is the "baton" concept subversion source code refers to? Maybe i > can > read somewhere about "batons" used in programming? Or is it a well- > known > term of some origin? I don't know the svn code at all... but I expect it is analogous to a baton that relay race team uses. The first person starts running with the baton... he runs his leg and passes the baton to the next runner on the team... who takes it through his part of the course. So, I would expect that a baton is some symbol or reference to an object that is passed from one function to another and each function performs its responsibility modifying the baton or possible using information stored in the baton. BOb
RE: svn 1.7 improvements: Large repo? (w/ 40,000 files)
> I notice that svn v1.7 is slated to have a new transfer protocol as > well as new WC module. > > ( http://subversion.apache.org/roadmap.html ) > > Right now, I have a repo with ~40,000 source and xml files. > > Full checkouts take forever. That's why you shouldn't be doing "full" checkouts very often. You should check out the portion of your repository that you need to work on. Also, you also shouldn't need to checkout very much. Once you have a working copy you are mostly doing "update" which just brings down the modified files since your last checkout/update. > > My machine is pretty beefy, so that's not the bottle neck. Network > speed to the remote svn server is OK, but not terrible, and > certainly not the bottle neck. It could be if it is a windows machine. Trying checking out to a RAM disk. I have found the performance is much much faster. > Assuming I upgrade my client to 1.7 when it comes out, my questions > are: > > - Will either of the above improvements help me if the server > _does_ get upgraded to v1.7? > > - Will either of the above improvements help me if the server _does > not_ get upgraded to v1.7? Most of the wc perf improvements will probably work with a 1.6 server. But, I expect there are some that won't. All that said, I never heard that there will be a new protocol. BOb
RE: svn 1.7 improvements: Large repo? (w/ 40,000 files)
> > My machine is pretty beefy, so that's not the bottle neck. > Network > > speed to the remote svn server is OK, but not terrible, and > > certainly not the bottle neck. > It could be if it is a windows machine. Trying checking out to a > RAM disk. I have found the performance is much much faster. > > > Any recommended ram disk software? I've used this one: http://memory.dataram.com/products-and-services/software/ramdisk It is free for up to 4GB disks. There is also a topic on this over at superuser.com: http://superuser.com/questions/34388/whats-the-best-ramdisk-for-windows BOb > > > All that said, I never heard that there will be a new protocol. > > > It's on: http://subversion.apache.org/roadmap.html > > Details sound pretty cool. > Particularly the pipelining and parallel request items. > > >
RE: migrate svn 1.4 to 1.6
> I am planning a migrate/upgrade SVN server that work at windows > 2003 server . > > My current version is 1.4 and I want to migrate to 1.6 > > 1) Should I restart the windows server at the end of the process ? > Is it needed? > > 2) Do anybody have the step by step of a same experience? you shouldn't have to restart the service. But, you will have to restart the service that you are using, either Apache or svnserve daemon. BOb
RE: internal dirs showing up on update
> I have so SVN repos (subversion) and I use them with no proble. But > when we do updates/commints on client (tortoise) we always get teh > internal directories: > > conf > dav > db > hooks > locks > format > README.txt > > These es are internal and should not appear right? How do I remove > this? I assume these folder are in your repository. Just go into the repository browser in TortoiseSVn and delete the folders. BOb > > > /etc/subversion/config is as provided > > and my > /etc/apache2/mods-enabled/dav_svn.conf > > is more or less like this > > > > DAV svn > SVNParentPath /svn > SVNListParentPath on > AuthType Basic > AuthName " Repos" > AuthUserFile /etc/subversion/ > SSLRequireSSL > AuthzSVNAccessFile /etc/subversion/ > Require valid-user > > > > Thanks is advance > NC
RE: Betr.: htpasswd without apache
> "Ada Battousai" schreef op 18/02/2011 > 06:36:40: > > > I'm trying to make a local repository (protocol svn://, without > > apache) works with a password file with htpasswd entries. But my > svn > > does not recognize the passwords added there. > > How can I configure svn to make it work? > > That won't work. The htpasswd file is used by apache, not by SVN > itself. > If you want to use just svn:// (not svn+ssh://) I _think_ the only > option > is a plain text file containing usernames and passwords: > http://svnbook.red- > bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig > .svnserve.auth.users I'm pretty sure you can use LDAP with svnserve via the SASL support. BOb
RE: SVN Structure/advantages
> Hello, > I was working with some projects web that had this struture: > follows below. > > - All projects was in three branches. One branch for bugs, one > branch for improvement and one branch for deploy . > > So, I migrate each folder of project to a new project and began to > use a TRUNK and tags as recommended at svn book. > > > Formerly, at my "deploy tool", I was only using a branch for > deploy; > > Now I use a tag for each project to deploy. > > At work, I had to do just one switch for all projects. > > Now I have to do a switch for each project to work. (the projects > has dependence). > > I am new at SVN, and a have a question about it: > > > 1) What the advantages of to use the best practices (trunk and > tags) as recommendded at svn book, if my work is more hard? trunk/branches/tags is just a recommended way to organize your repository, it is by no means required. We use it for some projects and not for others. There is nothing wrong with your promotion type layout if that is what works best for you. I think the main advantage to the recommended layout comes with open source projects that use svn... since everyone will understand that layout and will have a very good idea what is what. but even with trunk / branches / tag... there is no specification of what is on trunk. Is that where stable/tested code is. Or is that where WIP code is? BOb
RE: migrate svn 1.4 to 1.6
> > I am planning a migrate/upgrade SVN server that work at > > windows 2003 server . > > > > My current version is 1.4 and I want to migrate to 1.6 > > > > 1) Should I restart the windows server at the end of the > > process ? Is it needed? > > As already mentioned, not the server but you will need to restart > apache > / avnserve. I would shut them down before hand to make sure that > you > can upgrade all the files svn files properly (this is windoze after > all). If your server never gets rebooted, now might be as good a > time > as any! > > > 2) Do anybody have the step by step of a same experience? > > http://stackoverflow.com/questions/1160761/how-to-upgrade-svn-1-4- > 4-r251 > 88-to-svn-1-6 > ...is the best out of the first page of search results. > > Remember that upgrading the server is only part of the picture. > Any new > repos you create will get all the benefits but existing repos will > not > get the full benefits unless you can find the time to do a > dump/load. Not 100% true, you can run svnadmin upgrade on your repositories also. It takes much less time. A dump load of our primary repo takes about a day. svnadmin upgrade (from 1.5 to 1.6 ran in about 10 mins on our repo.) BOb > You don't have to do this but I would think about it... Remember > the > clients too.
RE: internal dirs showing up on update
> On Fri, Feb 18, 2011 at 13:19, Nuno Carapeto > wrote: > > > > > > On Thu, Feb 17, 2011 at 8:56 PM, Blair Zajac > wrote: > >> > >> On 2/17/11 12:50 PM, Bob Archer wrote: > >>>> > >>>> I have so SVN repos (subversion) and I use them with no > proble. But > >>>> when we do updates/commints on client (tortoise) we always get > teh > >>>> internal directories: > >>>> > >>>> conf > >>>> dav > >>>> db > >>>> hooks > >>>> locks > >>>> format > >>>> README.txt > >>>> > >>>> These es are internal and should not appear right? How do I > remove > >>>> this? > >>> > >>> I assume these folder are in your repository. Just go into the > repository > >>> browser in TortoiseSVn and delete the folders. > >> > >> It sounds like somebody checked in a copy of a repo into the > repo, in > >> which case it's safe to delete. > >> > >> Blair > > > > Ok! > > Thank you all for the support. > > As suggested I just deleted it and committed them and its working > properly. > > Still I found it odd that some random user would put them there > when they > > don't actually know what folders are in the server. > > Plus it happened in at least 2 repos. I suspect some random > client bug :S > > Any way, thanks a lot for the help > > Not that surprising, actually. I've had a number of users who, > early > in their use of Subversion, would create a repository when they > meant > to create a working copy (checkout). It's very possible that > someone > did this, then realized their error, did a checkout to the same > directory, then committed everything. Agreed... I very much doubt there is a client bug... more like a "user" bug. BOb
RE: Assistance with SVN layout from CVS
> Hi, I have been using CVS since 1998 and I am now finally moving to > SVN. After having studied SVN for the last few weeks, getting the > server prepared and working with clients, both console and GUI, I > think I can use the accumulated experience for a simple migration > and > new SVN layout. > > We have had many revisions since 1998 and I don't think its worth > the > effort to try to re-record all this under SVN. But what I have > done > is under CVS is checked out l the projects from the last 10 > revision > tags into their own folders by tag name: > > \rev6_3_452_5 > \rev6_3_452_6 > \rev6_3_452_7 > \rev6_3_452_8 > \rev6_3_452_9 > \rev6_3_453_1 > \rev6_3_453_2 > \rev6_3_453_3 last official release > \rev6_3_453_4 next pending official release > \rev6_3_453_5 I would consider this a "branch" w/ one project > off > 453_3 > > There are at least in total 100+ projects in the total system, but > they are not all in each tagged revision, only whats changed for > that > release. i.e, 453_5 has one project with some exploratory code. It > was > by mistake (pre-mature) that it was tagged since this code will not > be > used, but I would like to see how that is applied via SVN branches. > > I "almost" got the idea of the SVN branch, tags and truck but I am > finding myself a little lost which way to go here. > > I can really use some help here. The above would probably be the > simplistic I can make it to go forward and was hoping to see how > others would lay it out with the SVN framework. I now SVN offers > flexibility and one can move things around later, but what would > you > suggest here? > > I decided to post because after I checked out the revision tags, I > was > wondering if I should do something like: > >for each revision (upto 453.3) > - import revision into trunk > - do a "cheap copy" of current trunk into tags > > with the idea that I would end up with: > >- branch >how do I get that one project 453.5 exploratory code here? >- tags > \rev6_3_452_5 > \rev6_3_452_6 > \rev6_3_452_7 > \rev6_3_452_8 > \rev6_3_452_9 > \rev6_3_453_1 > \rev6_3_453_2 > \rev6_3_453_3 >- trunk > \current < current would be 453.3 > > and if this the basis for my new SVN layout and then when when I > done > with 453.4 development I can commit into the trunk and also create > a > cheap copy into tags "rev6-3_453_4" > > I speaking as I know what I am doing. :) But maybe I am now. Note, > it > is critical what we maintain a version numbering like 6.4.453.4 > (label > wise) as that is how the product has worked since 1998. I would not > how the SVN revision # only idea would apply yet. I don't use the > CVS > revision numbers eithers. Only tags. > > I hope I can get some input here. Thanks. I would start with your repository empty. Create your trunk / branches /tags in it. Then I would check-out trunk to a folder. Once that is checked out I would copy the contents of \rev6_3_452_5 to the working copy folder. Do an svn add . then submit svn ci -m "Initial import of source" Once I have done this I would create the tag: svn cp ~/trunk ~/tags/rev6_3_452_5 from there I would copy the contents of \rev3_452_6 into the working copy... then do an svn add. Also do a compare of the files and see if any files in the older rev no longer exist in the newer rev and delete them. Once that is done do your commit and tag. Keep doing this until you have gotten to the contents of rev6_453_3 into the working copy, hence trunk. Now create your branch: svn cp ~/trunk ~/branch/rev6_3_453_5 No check out that branch and put the source for _5 into it an commit. I think that will get you where you want to be, without having multiple copies of your projects in your repository and just using the cheap copies of svn. Also, this all assumes the procedure of release from trunk with future versions in branches. (Not my favorite way to go but many people us it.) BOb
RE: recursive propedit
> I am executing: > svn propedit svn:ignore . > > But this works only on the current directory. I like to have it > work > on all the directories beneath the current directory also. And if > possible on the directories that will be created in the future. > > Is this possible? If you ignore a folder... you are also ignoring any contents or sub-folders of that folder. For example, if you have: /MyPath/Here/IngoreThis svn:ignore IgnoreThis as a property of the Here folder... the IgnoreThis and all its contents will be ignored. Or, is that not what you are asking? BOb
RE: SVN always thinks a few certain files need to be merged
> On 03/23/2011 08:02 PM, David Huang wrote: > > > > On Mar 23, 2011, at 7:52 PM, Pat Farrell wrote: > > > >> On 03/23/2011 08:34 PM, Konstantin Kolinko wrote: > >>> You are not giving much specifics, so how can people know what > is going on > >>> in your case? > >> > >> Specifics for complete 100% reproducable problem: > >> > >> do svn update for whole project > >> create branch from trunk > >> change one source file, not the one with the bogus mergeinfo, > commit it. > >> merge branch back to trunk > >> > >> before you commit the trunk, do a svn status > >> You will see the bogus mergeinfo listed as a change to the > trunk. > > > > > > If you're sure that the mergeinfo is bogus, why not just delete > it? > > e.g., svn propdel svn:mergeinfo > fnfapp/src/java/com/fnfbook/bean/FilterListBase.java > > > > http://www.collab.net/community/subversion/articles/merge- > info.html might be worth a read too. > > > > My specifics are substantially similar to those of Mr. Farrell, > which > are essentially what I laid out in my original post that started > this > thread. And yet Mr. Kolinko complains I've not given him enough > specifics. One specific I can give is that our SVN server is still > 1.5.4. > > Clearly something is broken here. If mergeinfo constantly requires > merging when there are no changes, how is that to be fixed? The > documents that have been posted here provide way too much > information > for my use case. I should not need to understand that much of > subversion internals to fix this problem! Basically, what it comes down to is the fact that the merge info on the files does not match the merge info on the parent folders. Whenever and item in the path has mergeinfo and a merge is performed that merge info is updated. (this is supposed to stop happening as of 1.7 I believe). As long as there is merge info on a file that isn't in the parent folder the merge info will remain at the file level. Once they match the merge info in the children (files) will be elided and you won't see this happen again. I assume every time you see these property changes you are committing them? BOb
RE: SVN always thinks a few certain files need to be merged
> On 03/23/2011 08:09 PM, Pat Farrell wrote: > > On 03/23/2011 09:02 PM, David Huang wrote: > >> If you're sure that the mergeinfo is bogus, why not just delete > it? > >> e.g., svn propdel svn:mergeinfo > fnfapp/src/java/com/fnfbook/bean/FilterListBase.java > > > > I'm sure. I'll try that. > > I have not tried it before, because I can't figure out what in > the heck > > mergeinfo was supposed to do, and there have been lots of > comments that > > it really didn't work properly in 1.5, and that it works > differently in > > 1.6, etc. > > > > in other words, I didn't know to do that. > > > > Or even that such as command existed. > > > > For me, blowing up all mergeinfo would improve SVN. > > > > propset/propedit/propdel is opaque to me, everytime I try to use > it, I > > spend an hour dorking around trying random combination of specs, > > directories, etc. > > > > Again, the SVN gurus need to listen to Mr. Farrell and myself here. > > Ordinary users should not be required to understand mergeinfo at > the > level that is being presented here. > > What is it? > Why is it needed? > If it gets screwed up, and you delete it, what are you losing? You > must > be losing something, else why have it in the first place? > > It's not right to suggest simply getting rid of it without > explaining > the full consequences of that action. > > This is how I got in trouble in the first place. > > Have to agree with Mr. Farrell: > > > For me, blowing up all mergeinfo would improve SVN. > > > > propset/propedit/propdel is opaque to me, everytime I try to use > it, I > > spend an hour dorking around trying random combination of specs, > > directories, etc. > > Unless the pros here can do better than they've done in explaining > this > whole area is a real black eye for SVN. > > My repository is still at 1.5.4. I can have my SCM team upgrade me > to > 1.6.something. Should I do this, and would it help this problem? It depends on what version you were on... but early versions of 1.5 did create alot more mergeinfo than was necessary... and also it was created in some instances when it shouldn't have been. I highly suggest you get up to date. However, that won't "resolve" this issue... although it isn't really an issue... see my previous email. BOb
RE: SVN always thinks a few certain files need to be merged
> On 03/24/2011 05:01 PM, Bob Archer wrote: > >> On 03/23/2011 08:02 PM, David Huang wrote: > >>> > >>> On Mar 23, 2011, at 7:52 PM, Pat Farrell wrote: > >>> > >>>> On 03/23/2011 08:34 PM, Konstantin Kolinko wrote: > >>>>> You are not giving much specifics, so how can people know > what > >> is going on > >>>>> in your case? > >>>> > >>>> Specifics for complete 100% reproducable problem: > >>>> > >>>> do svn update for whole project > >>>> create branch from trunk > >>>> change one source file, not the one with the bogus mergeinfo, > >> commit it. > >>>> merge branch back to trunk > >>>> > >>>> before you commit the trunk, do a svn status > >>>> You will see the bogus mergeinfo listed as a change to the > >> trunk. > >>> > >>> > >>> If you're sure that the mergeinfo is bogus, why not just delete > >> it? > >>> e.g., svn propdel svn:mergeinfo > >> fnfapp/src/java/com/fnfbook/bean/FilterListBase.java > >>> > >>> http://www.collab.net/community/subversion/articles/merge- > >> info.html might be worth a read too. > >>> > >> > >> My specifics are substantially similar to those of Mr. Farrell, > >> which > >> are essentially what I laid out in my original post that started > >> this > >> thread. And yet Mr. Kolinko complains I've not given him enough > >> specifics. One specific I can give is that our SVN server is > still > >> 1.5.4. > >> > >> Clearly something is broken here. If mergeinfo constantly > requires > >> merging when there are no changes, how is that to be fixed? The > >> documents that have been posted here provide way too much > >> information > >> for my use case. I should not need to understand that much of > >> subversion internals to fix this problem! > > > > Basically, what it comes down to is the fact that the merge info > on the files does not match the merge info on the parent folders. > Whenever and item in the path has mergeinfo and a merge is > performed that merge info is updated. (this is supposed to stop > happening as of 1.7 I believe). As long as there is merge info on a > file that isn't in the parent folder the merge info will remain at > the file level. Once they match the merge info in the children > (files) will be elided and you won't see this happen again. > > > > I assume every time you see these property changes you are > committing them? > > > > > > BOb > > > > > > > > > Yes, and thanks. What I take from your explanation is that > removing the > merge info from these files is both safe and effective in getting > where > I want to go (not be bothered by this anymore). Is that right? It's not that simple, but it can be. My question would be.. what is the difference between the mergeinfo on these files and the merge info on your project root (which is where you should always perform your merges for this to work best). Once you know the difference the question is "why are they different". If it was due to a bug in svn then you should be ok with some manual changes. If it is due to some revision not being merged in at the project root level then I would ask, why aren't they merged at the root level? > > Is there any downside? > Only you can answer that based on doing the above investigation. If you don't remove needed mergeinfo then there is no downside. ;) BOb
RE: Tortoise and editing files on a server
> I am new to subversion and also not a Windows user. > > I am asked to create a repository for a company. The programmers > will > be using Windows PC's to do there work. But the files they are > working > on will be on a web server, not on there local PC. So there edits > will > be on remote files. In principal they want to use tortoise. How > should > this be implemented? Frankly, my recommendation would be not like that. Each user should have a private working copy... for best performance it should be on their local PC. BOb
RE: Using tags with SVN
> I'm currently thinking about migrating from CVS to SVN, since SVN > is said to be the successor of CVS. > When analyzing the differences between CVS and SVN I found tags are > treated in a different way in SVN, than they were treated in CVS, > because the tag concept in SVN is: A tag is just a "snapshot" of a > project in time. > This differs somewhat from the CVS concept of a tag: "You can use > the tag command to give a symbolic name to a certain revision of a > file." > We use tags in CVS to identify the files which have passed module > tests and should make it into our integration test environment. So you are saying you test "files" in isolation? That seems a bit unusual I think. In svn you use a "tag" to give a symbolic name to a certain revision also. It's really not all that different. > When they have passed the integration tests we use a different tag > to identify the files, which make up the software in/for our > production environment. In addition to that our development model > is not release driven. As a result we do not tag the HEAD of our > complete source tree at a particular point in time. As soon as we > have finished development of a feature or functionality we tag the > files which have been changed with a tag named "Q". In a different > workspace we check out the "Q" tagged source tree. This gives us > the possibility to go on developing a feature while doing the > integration test on a previous revision of it and have a source > tree which consists of files, which reached the state of being > ready for integration tests or for production at different points > in time. In my opinion branches would be too complicated to achieve > the same functionality. > Does anyone have an idea how to achieve this flexibility and ease > of use with branches in SVN? What you described above is exactly what branches are for. Why do you think this would be complicated? This is exactly the description of a branch for release use case. I think you are over thinking this... how is tagging a revision that contains the changes for a feature with a "Q" than tagging each file with a "Q"? BOb
RE: Advice on upgrading svn and moving to new server
> > On Wed, Mar 30, 2011 at 3:17 PM, Daniel Shahaf > wrote: > > Kevin Grover wrote on Wed, Mar 30, 2011 at 08:13:34 -0700: > >> When upgrading, mostly you can still access old repositories. > SOMETIMES > >> they will be silently upgraded in someways > > > > I don't know that the above sentence is correct. Can you give > > an example of a scenario when that happens? > > Working copies will be upgraded silently. A working copy is not a repository though. BOb
RE: Using tags with SVN
> > > I'm currently thinking about migrating from CVS to SVN, since > SVN > > > is said to be the successor of CVS. > > > When analyzing the differences between CVS and SVN I found tags > are > > > treated in a different way in SVN, than they were treated in > CVS, > > > because the tag concept in SVN is: A tag is just a "snapshot" > of a > > > project in time. > > > This differs somewhat from the CVS concept of a tag: "You can > use > > > the tag command to give a symbolic name to a certain revision > of a > > > file." > > > We use tags in CVS to identify the files which have passed > module > > > tests and should make it into our integration test environment. > > > So you are saying you test "files" in isolation? That seems a bit > unusual I think. > > Sorry Bob, I was not precise concerning this point. "Isolation" > here means, that the system where we test is not integrated with > other systems. And, yes, the files are tested together with the > rest of the files from the cvs head. > > > In svn you use a "tag" to give a symbolic name to a certain > revision also. It's really not all that different. > > Yes, you are right. The difference is, that e.g. the "Q" tag is > shifted further when a new feature added to the file shall be > tested in the QA environment, which is fully integrated. The > features I'm talking of are quite fine grained. Due to that it > would lead to lots of branches, if we used a branch for each of > them. So how do you keep them isolated now? > > > > When they have passed the integration tests we use a different > tag > > > to identify the files, which make up the software in/for our > > > production environment. In addition to that our development > model > > > is not release driven. As a result we do not tag the HEAD of > our > > > complete source tree at a particular point in time. As soon as > we > > > have finished development of a feature or functionality we tag > the > > > files which have been changed with a tag named "Q". In a > different > > > workspace we check out the "Q" tagged source tree. This gives > us > > > the possibility to go on developing a feature while doing the > > > integration test on a previous revision of it and have a source > > > tree which consists of files, which reached the state of being > > > ready for integration tests or for production at different > points > > > in time. In my opinion branches would be too complicated to > achieve > > > the same functionality. > > > Does anyone have an idea how to achieve this flexibility and > ease > > > of use with branches in SVN? > > > What you described above is exactly what branches are for. Why do > you think this would be complicated? > > I'm quite new to svn, 'm not yet familiar with it and with the set > of commands. Consider the following case: main development is done > in trunk and in branches, perhaps. In order to provide a stable > version of my files for testing it in my integrated environment I'm > using a branch named "Q". A new feature is implemented by one of my > colleagues. What would he have to do to get the files making up his > new feature into the "Q" branch without losing its connection to > the file in trunk? So, basically Q is your "stable" branch? You would merge that feature from trunk to Q. If you developed it in the feature branch you would merge the feature back to trunk and then merge that into Q. But, if you follow the unstable trunk pattern then you probably don't need feature branches. > > > I think you are over thinking this... how is tagging a revision > that contains the changes for a feature with a "Q" than tagging > each file with a "Q"? > > My apologies, my English is not that good to understand what you > mean with this question. No problem... once you understand tags in svn they really aren't that much different and you can answer all your questions. BOb
RE: how to avoid text and tree conflict
> I read the SVN book, as there are three type conflicts: text, > tree and > properties conflict. However, I wanna know why it is a conflict. > For > example, if there is a text conflict when I do merging code, I just > know > there is an conflict but don't know why it is a conflict. It is a conflict because two people changed the same line of code. So, the software can't know which line of code you want to remain after it merges them... you have to tell it. You could choose one line, the other line, or even combine them in some way. BOb > > So could u provide me some resource or hints what are the judge > rules > for SVN to address it is a conflict, in this case, I can avoid more > conflict when I'm coding or merging. I concert the text and tree > conflict more. > > Regards, > Su Heng > > -- > QQ :49757862 > MSN:suh.ste...@hotmail.com > Mobile: (0512)60780554 >
RE: release date of Subversion 1.7
> Hi alltogether, > is a reliable release date of Subversion 1.7 available with info > about included or not included features? We need that for our > strategy planning. > > > Thanks in advance > Hartmut My plan would be plan to use 1.6 for another two years. 1.7 has been 3 months away for several years now. BOb
RE: how to avoid text and tree conflict
> On Mon, 2011-04-04 at 10:26 -0400, Bob Archer wrote: > > > I read the SVN book, as there are three type conflicts: text, > > > tree and > > > properties conflict. However, I wanna know why it is a > conflict. > > > For > > > example, if there is a text conflict when I do merging code, I > just > > > know > > > there is an conflict but don't know why it is a conflict. > > > > It is a conflict because two people changed the same line of > code. So, the software can't know which line of code you want to > remain after it merges them... you have to tell it. You could > choose one line, the other line, or even combine them in some way. > > > > BOb > > > > > > > > > > > > So could u provide me some resource or hints what are the > judge > > > rules > > > for SVN to address it is a conflict, in this case, I can avoid > more > > > conflict when I'm coding or merging. I concert the text and > tree > > > conflict more. > > > > > > Regards, > > > Su Heng > > > > > > -- > > > QQ :49757862 > > > MSN:suh.ste...@hotmail.com > > > Mobile: (0512)60780554 > > > > > > > Hi Bob, > > What about different lines? > trunk file node@r1 > node: > - > line1 > - > > create branch node1(node@r2), node2(node@r3) > > edit node@r2 under branch node1 > - > line1 > line2 > - > submit and get node@r3 > > edit node@r3 under branch node2 > - > line1 > > line3 > - > submit and get node@r4 > > edit node@r1(or merge branch node1) under trunk > - > line1 > line2 > - > submit and get node@r5 > > finally, merge branch node2@r4 to trunk can get conflict. > > <<<<<<< .working > line1 > line2=== > line1 > > line3>>>>>>> .merge-right.r4 > > > I though node2@r4 will be merged to node@r5 like this: > - > line1 > line2 > line3 > - > > but not. > Because... ...in the node1 branch you modified line2 making it read "line2". ...in the node2 branch you modified line2 making it "" and line 3 making it "line3" When you try to bring these together svn is going to look at the base (r1) of each file. It is going to see that line2 is different from base in both the merge target and the merge source. It also sees that those changes are different. That is a conflict. svn doesn't know whether to use the "line2" content from node1 branch or the "" content from node2. It may seem obvious to you that you don't want the blank like and you want it to say "line2"... but svn has no way to know this. Perhaps the blank line is what you want in the result. BTW: This happens even in normal use... since an update it also essentially a merge. Let's assume we have a file call it test.txt in a repository with the following lines: line1 line2 line3 line4 We each have it checked out to our working copies. I make a change to the file so it looks like this, and check it in: line1 line3 line4 (I have blanked line2, well really it contains a line feed). You make a change to the file so it looks like this: line1 line2a line3 line4 You try to commit and you get an error that it is out of date. So you do an update. svn sees that you changed line2 as did the latest HEAD version be comparing them to the common base. This is a conflict... a person has to resolve it. svn can just assume, oh a line with text is more important (or correct) than a line with just a line feed. And if it did do this you would not be very happy. That all said, we have found in our day to day use of svn we rarely see conflicts like this. Of course, the above is different than tree conflicts which occur for path change reasons rather than file content reasons. BOb
RE: Build project in pre-commit
> Thanks for your answer. Our commits to /trunk are supposed to be > done rarely. > Basically we want to exclude source code of projects that for some > reasons cannot be built centrally (on the server where the > repository > is). > A project consists of java files in a directory and an ant script. > Unfortunately I have not found any well-known software to help with > this kind of buildings. Team City supports pre-tested commits. from their web site: "With TeamCity you can build, check and run automated tests on the server even before committing your changes - keeping your code base clean at all times. Optionally, you can set up TeamCity to automatically commit changes to your version control each time they pass all checks." BOb
RE: Build project in pre-commit
> > Thanks for your answer. Our commits to /trunk are supposed to be > > done rarely. > > Basically we want to exclude source code of projects that for > some > > reasons cannot be built centrally (on the server where the > > repository > > is). > > A project consists of java files in a directory and an ant > script. > > Unfortunately I have not found any well-known software to help > with > > this kind of buildings. > > Team City supports pre-tested commits. from their web site: > > "With TeamCity you can build, check and run automated tests on the > server even before committing your changes - keeping your code base > clean at all times. Optionally, you can set up TeamCity to > automatically commit changes to your version control each time they > pass all checks." > Another option would be to do all your development on a branch. Have you build scripts build from that branch. IF the build is successful perform a merge to trunk. If the build fails, don't do the merge. Since branch is never checked into there shouldn't be merge conflicts. (well, tree conflicts would still be possible.) BOb
RE: Question to Setup and Implement Subversion
> I have a customer that is interested in purchasing and utilizing > Subversion. I want to be sure that we architect the > server/repository on the correct solution and couldn’t find much > information on the recommended implementation path and architecture > setups. If anyone is able to provide me with a little insight or > direction to where I can find that information, I would be most > grateful! You don't need to purchase subversion but you can if you want. ;) Have you read this book? http://svnbook.red-bean.com/nightly/en/svn-book.html It tells you pretty much all you need to know. Of course, after you grok it you can come back here and ask more specific questions. BOb
RE: beginner admin question: no repository found
> The machine on which my svn repository lives was recently upgraded. > I didn't have svnserve in a run-on-reboot script, so I started it > by hand (log in as "svn", then type "svnserve -d"). But whenever I > make any requests of the server (e.g. "svn ls svn://localhost", > much less "svn update"), I get the error message "svn: No > repository found in 'svn://localhost'". I then do a "ps x", and I > see something like > 11550 ?Ss 0:00 svnserve -d > 11556 ?Z 0:00 [svnserve] > > Is 11556 just a subprocess created to handle this request, which > for whatever reason hasn't gone away yet? Or is it the actually > svn server, which for some reason died as soon as it was asked to > do any work? > > I've done an "svnadmin verify", and the repository seems to be > fine. None of the config files has been changed in over a year, so > I doubt they're corrupted. Any ideas? It is possible it is binding to IPv6 rather than IPv4... I think you can pass in the IP you want it to bind to. http://www.bramschoenmakers.nl/en/node/287 BOb
RE: beginner admin question: no repository found
> > The machine on which my svn repository lives was recently > > upgraded. I didn't have svnserve in a run-on-reboot script, > > so I started it by hand (log in as "svn", then type "svnserve > > -d"). But whenever I make any requests of the server (e.g. > > "svn ls svn://localhost", much less "svn update"), I get the > > error message "svn: No repository found in > > 'svn://localhost'". I then do a "ps x", and I see something like > > 11550 ?Ss 0:00 svnserve -d > > 11556 ?Z 0:00 [svnserve] > > > > Is 11556 just a subprocess created to handle this request, > > which for whatever reason hasn't gone away yet? Or is it the > > actually svn server, which for some reason died as soon as it > > was asked to do any work? > > The former. The svnserve daemon spawns a child process for each > connection. On UNIX derivatives, zombie processes (the Z above) > are > created when a child process exits and the parent doesn't call > wait() to > retrieve its exit status. They get cleaned up by the init process > eventually. > > > > > I've done an "svnadmin verify", and the repository seems to > > be fine. None of the config files has been changed in over a > > year, so I doubt they're corrupted. Any ideas? > You need to tell svnserve where your repository is on the machine. > e.g. > > svnserve -d -r /path/to/repo > > It's probably trying to serve a repository rooted at /, which is > probably not where yours is. > I was going to say this, but I looked at the --help for svnserver and it doesn't seem to require the -r param. I figure it roots to the pwd. But, if he isn't running it from the repo root then yea... that! BOb
RE: duplicate merge conflict
> When I merge changes in SVN, the merges work well except for the > conflicts. For some reason, the merges are frequently (but not > always done twice). As an example: > <<<<<<< .working > <<<<<<< .working > const int SERIALIZE_FIELDS_DATA_LENGTH = 83; > === > const int SERIALIZE_FIELDS_DATA_LENGTH = 91; > >>>>>>> .merge-right.r462 > === > const int SERIALIZE_FIELDS_DATA_LENGTH = 91; > >>>>>>> .merge-right.r461 > It appears that I am merging the changes between versions 442 and > 462 into the current working copy so I don't understand where 461 > is coming from. > > This is happening both with Tortoise SVN (using Merge two different > trees) or from the command line with: > > svn merge tree1 tree2 --non-interactive Can you revert your merge and verify that your working copy didn't already have those r461 merge indicators in it. I know here people have checked in files that had unresolved conflict markers in them. BOb
RE: duplicate merge conflict
> -- > From: "Bob Archer" > Sent: Thursday, April 14, 2011 9:33 AM > To: "Daniel Walter" ; > > Subject: RE: duplicate merge conflict > > >> When I merge changes in SVN, the merges work well except for the > >> conflicts. For some reason, the merges are frequently (but not > >> always done twice). As an example: > >> <<<<<<< .working > >> <<<<<<< .working > >> const int SERIALIZE_FIELDS_DATA_LENGTH = 83; > >> === > >> const int SERIALIZE_FIELDS_DATA_LENGTH = 91; > >> >>>>>>> .merge-right.r462 > >> === > >> const int SERIALIZE_FIELDS_DATA_LENGTH = 91; > >> >>>>>>> .merge-right.r461 > >> It appears that I am merging the changes between versions 442 > and > >> 462 into the current working copy so I don't understand where > 461 > >> is coming from. > >> > >> This is happening both with Tortoise SVN (using Merge two > different > >> trees) or from the command line with: > >> > >> svn merge tree1 tree2 --non-interactive > > > > Can you revert your merge and verify that your working copy > didn't already > > have those r461 merge indicators in it. I know here people have > checked in > > files that had unresolved conflict markers in them. > > > I reverted to the original source and verified it. It had no > conflicts. > Then I did the merge again. The same thing happened and I ended up > with > duplicate conflicts again. > Is it possible you are merging in a range of non-contiguous revision? I believe that does a merge of each range separately. BOb
RE: RFE: Add Subversion keyword for year
> On Tue, Apr 19, 2011 at 12:02 AM, Daniel Becroft > wrote: > > On Tue, Apr 19, 2011 at 7:29 AM, Alex Vincent > wrote: > >> > >> I'm currently in the process of updating copyright notices where > I work. > >> To me, this is an ideal place for a SVN keyword: > >> > >> Copyright 2008-$Year$ MyCompany > >> > >> The SVN keywords listed in the online documentation list Date, > but it's > >> far too specific for a copyright. As an alternate, perhaps a > special > >> formatting keyword for dates could be established: > $Date()$, for > >> example. > > > > AFAIK, the $Date keyword works off the last time the particular > file was > > updated. Are you expecting this new $Year$ value to always be > current (ie > > 2011), or only reflect the year in which the file was last > modified (ie > > 2009)? > > IANAL and slightly OT, but... are you legally allowed to update the > copyright date without making a copyrightable modification of the > file? > If not; no tool can help you. A copyright notice is not necessary but recommended. The copyright notice applies to the "work" so, the whole program is the work. Putting a notice on every file is not required. However, the copyright notice applies to the work, so even if a specific file hasn't been changed the notice should be the same on every file, in your documentation, on your distribution media and probably displayed on a startup/splash screen/about page. Also, if you don't publish the source, the notice in the source is probably not needed. The date listed is the publication date. Also, any time you publish a substatial change it is a new "work" so the date should be updated. Usually all the publish dates are listed... Copyright 2010 Big Software, Inc. if you modify it and put out a release in 2011 you change it to: Copyright 2010-2011 Big Software, Inc. no changes until 2014 you would do: Copyright 2010-2011, 2014 Big Software, Inc. So, I wouldn't want this automatically done. I would recommend you use a copyright.txt file with the notice and have your build system or something inject it. BTW: IANAL either. BOb
RE: duplicate merge conflict
4.2.x-release +---o- > > > > > > > > If you don't want to think about revision numbers the following > pattern > > might help (or at least be inspiring) if you can live with (or > work > > around) > > limitations explained below. > > > > unstable changesmaintenance mode > > 4.2.x-release +-R-R... > > / . \ . \ > >/ \ ... \ > > / . v . v > > trunk --+-L---o-L--+o > >rWrX \ > > \ > > 4.3.x-release +---... > >unstable changes > > > > Basically, trunk never receives direct commits but only > reintegrate > > merges from the release branches. Note that in this pattern > release > > branches > > represent *future* releases you haven't already released for > production. > > Though maybe you did release them for testing purposes. > > Trunk is always in a releasable state. It is initially your > 4.1.x-release > > and becomes the 4.2.x-release once the 4.2.x-release branch has > been > > reintegrated for the first time. > > The 4.2.x-release branch now goes into maintenance mode and trunk > receives > > bug fixes from it via additional reintegrate merges. > > (You need to use the trick described at > > http://svnbook.red- > bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.a > dvanced.reintegratetwice > > to keep the release branch alive after reintegration.) > > > > This pattern avoids juggling with revision numbers but has some > drawbacks. > > You must consider trunk to be the stable and releasable state. > And you > > must > > stop maintaining older releases as soon as a new release hits > trunk. > > By the time you merge 4.2.x into trunk the 4.1.x release line has > reached > > end of life and will never receive additional updates. > > > This is an interesting pattern, but does not seem like it would > apply very > well to our development because we merge forward changes on a > regular basis. > > > > > This pattern works only with one future release line. You can > prepare the > > 4.3.x release on a release branch off trunk while 4.2.x is in > maintenance > > mode. > > The 4.3.x release branch then regularly syncs to trunk to receive > bug > > fixes > > originally made in 4.1.x which have been reintegrated into trunk. > > > > But in some scenarios this works quite well in spite of these > drawbacks. > > E.g. this pattern is being used in practice at a web shop where > trunk > > is deployed to production servers and release branches are > deployed to > > testing servers. There is no need to maintain old versions of the > website > > as soon as the latest release has gone live. > > > > Thank you for the suggestions. After learning how this worked, I > thought > there might be something that I am missing, but that does not seem > to be the > case. I think at this point, my best solution is still to use tags > and just > find the revisions for the tags before doing merges with svn info > if I think > that a particular merge will generate a lot of conflicts. If you are merging everything in there is no need to worry. That is the point of merge tracking. It will determine what has yet to be merged and select the correct revisions. Here is how we have our repo set up... rather than using trunk. We find it makes things easier. We basically "branch" when we start on a new release version. So we have something like this: 1.0.0 \ \ 1.0.1 +- \ \ 1.0.2 +-- We release from the version path (branch). Any hotfixes for that version are done on that branch. Then they are merged forward "up" version. So we merge a change made on the 1.0.0 to 1.0.1 then to 1.0.2 and forward. We "try" to only have our current release (1.0.1) and one back (1.0.0) in maintenance and then the in dev version (1.0.2). Of course, you always have that one client that doesn't want to upgrade and sales/support insists we do a fix... but we still just merge it up versions until it is merged into the unreleased dev version. BOb
RE: duplicate merge conflict
> > If you are merging everything in there is no need to worry. That > is the > > point of merge tracking. It will determine what has yet to be > merged and > > select the correct revisions. > > > > Here is how we have our repo set up... rather than using trunk. > We find it > > makes things easier. > > > > We basically "branch" when we start on a new release version. So > we have > > something like this: > > > > 1.0.0 > >\ > > \ > >1.0.1 +- > >\ > > \ > > 1.0.2 +-- > > > > We release from the version path (branch). Any hotfixes for that > version > > are done on that branch. Then they are merged forward "up" > version. So we > > merge a change made on the 1.0.0 to 1.0.1 then to 1.0.2 and > forward. We > > "try" to only have our current release (1.0.1) and one back > (1.0.0) in > > maintenance and then the in dev version (1.0.2). Of course, you > always > > have that one client that doesn't want to upgrade and > sales/support > > insists we do a fix... but we still just merge it up versions > until it is > > merged into the unreleased dev version. > > > > BOb > > > > > > > > This seems to describe my scenario quite well. What command do I > use to > merge. Also, how is your development tree structured. I would > think that > 1.0.2 would be the trunk in this scenario, but you don't have it > drawn that > way. Like I said, we don't even have a path named "trunk". The paths to the above versions in the repo would be like: svn://server/repo/project/v1.0.0 svn://server/repo/project/v1.0.1 (this was copied from the 1.0.0 path) svn://server/repo/project/v1.0.2 (this was copied from the 1.0.1 path) On my dev machine I have a dev root in my Users folder named "development". I check out each version to that. I DON'T use switch. I think it is too easy to forget which current version you are switched to. So, I would have all three version check out like this: Development\Project-v1.0.0 Development\Project-v1.0.1 Development\Project-v1.0.2 Weekly we do a merge. Let's say the oldest release with changes in 1.0.0. So, I would do something like: cd Development\Project-v1.0.1 svn merge svn://server/repo/project/v1.0.0 (I actually use TortoiseSVN but I think that is the command line version) I resolve and conflicts, build, test, commit. Once the build server gives me a green build I move to the next version. cd Development\Project-v1.0.2 svn merge svn://server/repo/project/v1.0.1 Rinse and repeat. Notice, I didn't specify and ranges. svn figures out what revisions from the source path have not yet been merged in for me. BTW: Just as an aside we do have a branches folder in the project and this is where we put feature branches. Although we don't use them too often, we have used them. BOb
RE: duplicate merge conflict
> > Like I said, we don't even have a path named "trunk". > > > > The paths to the above versions in the repo would be like: > > > > svn://server/repo/project/v1.0.0 > > svn://server/repo/project/v1.0.1 (this was copied from the 1.0.0 > path) > > svn://server/repo/project/v1.0.2 (this was copied from the 1.0.1 > path) > > > > On my dev machine I have a dev root in my Users folder named > > "development". I check out each version to that. I DON'T use > switch. I > > think it is too easy to forget which current version you are > switched to. > > So, I would have all three version check out like this: > > > > Development\Project-v1.0.0 > > Development\Project-v1.0.1 > > Development\Project-v1.0.2 > > > > Weekly we do a merge. Let's say the oldest release with changes > in 1.0.0. > > So, I would do something like: > > > > cd Development\Project-v1.0.1 > > svn merge svn://server/repo/project/v1.0.0 (I actually use > TortoiseSVN but > > I think that is the command line version) > > > > I resolve and conflicts, build, test, commit. Once the build > server gives > > me a green build I move to the next version. > > > > cd Development\Project-v1.0.2 > > svn merge svn://server/repo/project/v1.0.1 > > > > Rinse and repeat. > > > > Notice, I didn't specify and ranges. svn figures out what > revisions from > > the source path have not yet been merged in for me. > > > > BTW: Just as an aside we do have a branches folder in the project > and this > > is where we put feature branches. Although we don't use them too > often, we > > have used them. > > > > BOb > > > > This seems really nice and models my workflow very well, but I > followed the > documentation when I started using SVN and I have a trunk now. BTW: You can rename folders in svn if you want. ;) > 1. Since I have a trunk with a branch off of it, is it possible to > make > regular merges from my branch back to the trunk using the same > command? > i.e. (from trunk working copy) svn merge branch Yes. But you can't merge from branch to trunk if you have merged from trunk to branch. That is called a cyclic merge and it really confuses subversion. Well, I should say you can't do it automatically. You can specify the change set or revision if you want to do it manually. Normally when you create a branch you can merge any changes made to it back into its ancestor (where you copied from) using: cd \trunk svn merge ^/branch/path You can repeat the above as much as you want. But, if you want to get something from trunk to branch you'll be in trouble. (there may be a way to do it, but I'm not sure the best way.) > 2. I just tried the above command and it started trying to merge > things from > months ago together. Is there any way to tell SVN what it should > use as a > baseline for automatic merges? I tried tried just letting it > finish and > then replacing all of the source files and doing a commit, but this > didn't > seem to have any effect. Issuing the command again gave the same > results. > I also tried --record-only which did the full merge anyway. Record only should only make changes to the properties and not the files. You can also just manually update the svn:merginfo on the trunk if you want. BOb
RE: svn prop_time and replacement
> I'm currently working at the Subversion support for one of our > applications (embedded via SharpSVN). > > Now, after operations like update and revert, we have to scan the > working copy for changes, to decide whether we have to re-read the > files > into our application. For file changes, we can use the file > timestamp > from the filesystem. But for property changes, we don't have this > possibility. > > The svn_info_t.prop_time or svn_wc_entry_t.prop_time members would > be > handy for that, but they're documented as unused since svn 1.4. > > I don't want to rely on dirty tricks as parsing the timestamp of > the > properties file in the .svn subdirectory, as this is doomed to > break on > SVN 1.7. Is there any official way to get the timestamp when the > properties part of a WC entry was last updated? > > Alternatively, I could think of a solution of using the > svn_wc_notify_t > notifications. But in the Source at > http://svn.collab.net/svn-doxygen/svn__wc_8h-source.html#l00910 > says > that this is meant for user notification purposes. > > So my second question is: Are those notifications reliable enough > in the > sense that we can use them to collect a list of all files to > rescan? > Duplicates and small amounts of false positives are tolerable, but > false > negatives introduce inconsistencies between our internal > representation > and the working copy. > > Thanks a lot! The second column of the status output shows the status of the dir/file properties. I assume you have access to the "svn status" command's API? BOb
RE: duplicate merge conflict
> >> Record only should only make changes to the properties and not > the files. > >> You can also just manually update the svn:merginfo on the trunk > if you > >> want. > > > > I think the problem is that because Daniel is using ancestrally > > unrelated trees for the left and right side of his merge diff > there > > is no merge-tracking (just like when the --ignore-ancestry option > is > > used). > > So any options related to merge-tracking (like --record-only) > have no > > effect. > > > > I think that what I am dealing with is ancestrally related now: > > (in 4.2 working copy) svn merge --record-only -r 222:473 > ^/branches/branch4.1 You can verified that branch4.2 is a child (copy of) branch4.1? > > Here I am attempting to generate merge info for the changes since I > started > the branch at r222 up to the point where I figured out everything I > have > been doing wrong r473. > > It seems like --record-only should generate an error if there is a > problem > instead of corrupting my working copy. It is a simple matter to > revert > this, but it is not very useful for understanding what I did wrong. > > I wanted to check my version numbers, to make sure that I am using > recent > versions. My client is 1.6.13. Is there a way to get the server > version > from the svn client? I guess my question is... 1. Can you do the merge --record-only without specifying revisions. 2. What is it corrupting exactly? BOb
RE: duplicate merge conflict
> -- > From: "Bob Archer" > Sent: Thursday, April 21, 2011 11:17 AM > To: "Daniel Walter" ; "Stefan Sperling" > > Cc: > Subject: RE: duplicate merge conflict > > >> >> Record only should only make changes to the properties and > not > >> the files. > >> >> You can also just manually update the svn:merginfo on the > trunk > >> if you > >> >> want. > >> > > >> > I think the problem is that because Daniel is using > ancestrally > >> > unrelated trees for the left and right side of his merge diff > >> there > >> > is no merge-tracking (just like when the --ignore-ancestry > option > >> is > >> > used). > >> > So any options related to merge-tracking (like --record-only) > >> have no > >> > effect. > >> > > >> > >> I think that what I am dealing with is ancestrally related now: > >> > >> (in 4.2 working copy) svn merge --record-only -r 222:473 > >> ^/branches/branch4.1 > > > > You can verified that branch4.2 is a child (copy of) branch4.1? > > > > > ---trunk >\ \ > \ 4.1 \ 4.2 > > Both branch 4.1 and 4.2 are copies of the trunk at different > points. I'm going to leave it to Stefan to comment on this one. I'm not sure if in this case it will work. 4.2 is not an ancestor of 4.2 but they have a common ancestor. I think in this case you need to merge 4.1 into trunk then merge trunk into 4.1. This funky stuff is why we went to the repo organization that I mentioned in a previous email in this thread. BOb > > >> > >> Here I am attempting to generate merge info for the changes > since I > >> started > >> the branch at r222 up to the point where I figured out > everything I > >> have > >> been doing wrong r473. > >> > >> It seems like --record-only should generate an error if there is > a > >> problem > >> instead of corrupting my working copy. It is a simple matter to > >> revert > >> this, but it is not very useful for understanding what I did > wrong. > >> > >> I wanted to check my version numbers, to make sure that I am > using > >> recent > >> versions. My client is 1.6.13. Is there a way to get the > server > >> version > >> from the svn client? > > > > I guess my question is... > > > > 1. Can you do the merge --record-only without specifying > revisions. > > > > 2. What is it corrupting exactly? > > > > BOb > > > With or without specifying revisions and with or without --record- > only it is > merging from the beginning of the 4.1 branch to a later point on > the trunk. > I am going to get the SVN server updated and try this again thou I'm not sure if updating the server is going to change anything. BOb
RE: repo on Windows -- why not?
> in most cases, you don't want to host a SVN repository on Windows. Why? We are a windows "shop" and we have windows servers and we host on windows. I've seen zero problems. I think this type of anti-ms FUD is going to be bad for svn if it is widely said and published. > what are common reasons to prefer other platforms, e.g. Linux? I'm > looking for some accurate arguments and facts for my book. Thanks > for > your help. Ok, common reasons to prefer one over the other, well laid out is perfectly reasonable. ;) BOb
Re: repo on Windows -- why not?
Hi Mike, I recently had a client who insisted on VisualSVN on Windows. It was a very quick and easy setup. I would normally always put the repo on Linux, but some folks are just more comfortable with what they know or they may not even have a linux server.. Bob http://www.linkedin.com/in/BobAiello http://cmbestpractices.com On 4/22/2011 10:52 AM, Michael Hüttermann wrote: are there any arguments to prefer Windows? (beside arguments that you drive a Windows shop) ok, looks like I have to adjust the section a bit. Am Freitag, den 22.04.2011, 10:39 +0200 schrieb Bob Archer : in most cases, you don't want to host a SVN repository on Windows. Why? We are a windows "shop" and we have windows servers and we host on windows. I've seen zero problems. I think this type of anti-ms FUD is going to be bad for svn if it is widely said and published. what are common reasons to prefer other platforms, e.g. Linux? I'm looking for some accurate arguments and facts for my book. Thanks for your help. Ok, common reasons to prefer one over the other, well laid out is perfectly reasonable. ;)
RE: Commit to trunk and branch in a single commit
> Often I have small changes that apply to a branch and the trunk > alike. Of > course I cannot do a normal merge because the local change doesn't > have a > revision number yet. > > If I copy the change from the branch to the trunk or vice versa and > then > commit it in one single commit, will it break merge tracking? If you do commit the same change manually to trunk and branch and then you try to do a merge you will get a conflict. You can do a --record-only merge after the fact to resolve that problem though. Or just deal with the conflict when you do finally merge. BOb
RE: My full name and email address open to all on web?
> I did a search of my email address in IE8 - to see what information > is out there identifying me to everyone! > > I found this link: > http://mail-archives.apache.org/mod_mbox/subversion- > dev/201001.mbox/%3C1A60AD0697A8964EA981A8DE6F1DAE0908F8FCA0@BGGWRMB > 01.bge.ie%3E > > and got my full name and work email address in an apache archive! > > Was it intentional to post the archives up on the web for all to > see - in which case, how do I get this article removed? > > Regards > Robert Beattie This email that you just sent that I am replying to has your name and email address in it. It will be archived. I'm not sure how it identifies "you". I'm not sure how you are expecting your email/name to be private when you post it to a publically accessible email list. BOb
RE: Trying (failing) to limit access to one user
> On Tue, 2011-04-26 at 16:45 -0500, kmra...@rockwellcollins.com > wrote: > > > I've found using "*" to be non intuitive. Try: > > > > [/] > > $authenticated=rw > > jon= > > Thanks for the reply! Unfortunately, jon still has full access... > > -Alan Are you sure he has "full" access? Path based auth will not hide the folder names in root. He will still be able to see them. BOb
RE: Trying (failing) to limit access to one user
> > On Tue, 2011-04-26 at 16:45 -0500, kmra...@rockwellcollins.com > > wrote: > > > > > I've found using "*" to be non intuitive. Try: > > > > > > [/] > > > $authenticated=rw > > > jon= > > > > Thanks for the reply! Unfortunately, jon still has full access... > > > > -Alan > > Are you sure he has "full" access? Path based auth will not hide > the folder names in root. He will still be able to see them. > Oh wait.. the above I assume jon is authenticated so he would of course have access in this case. Deny doesn't trump allow as it does in other systems. Also there is the same problem with: [/] *=rw jon= Because jon is a subset of * which gives him read/write access. BOb
RE: SVN Update is not happening from the server, though the status shows "Completed"
> One of my team members made few changes to existing files in SVN. > When I performed SVN update, status shown is "Completed : > " > But actually the files are not updated when checked for the > changes. > I tried to perform SVN clean and update, even then it is the same. > > When I deleted the files and then performed update I now saw the > changes made are reflecting properly. > > But I cannot delete the files and do SVN update every time I want > to see the updated files as it is a time consuming activity. > > This issue is seen for the first time in my machine. Please help us What version of svn? Is this still happening with the new checkout? It is possible you had a sparse checkout so you weren't getting the new files. I think there was an older version that had a bug which would label a checked out folder as immediate rather than full depth giving you a sparse checkout. BOb
RE: Trying (failing) to limit access to one user
> > Perhaps > > > > [/] > > ~jon = rw > > Nope. jon still able to check out the entire repository tree. > > So far, it seems that the only rules that make any difference are > "* =" > and "$authenticated =". These give everybody access. Without one of > these present, nobody has access. And now I can add "~anyname =" to > that > list. > > Using "anyname =" doesn't seem to have any effect at all on access. > It > certainly doesn't grant any access to anyname. > > This is why I mentioned in my OP that I thought this might be me > misunderstanding the meaning of "anonymous access" in this context. What authentication method are you using? I'm guessing while *= works but "jon=" (or other user names) doesn't that isn't the full user name that svn sees. If you look at your log are the usernames the ones you are expecting and putting into the authz file? BOb
RE: just upgraded to svn 1.5 - confused
> On Thu, Apr 28, 2011 at 20:27, Totte Karlsson > wrote: > > Someone said that merges are easy.. I have read the svn book > about merges > > but it does not help. > > > > I create a branch and I can keep it synchronized with the trunk. > > I can even re-integrate the branch with the trunk. > > > > From now on, it seems the branch is useless since I can't > continue working > > on it and re-sync with the trunk without getting absolutely > nonsense > > conflicts.. :) > > > > What is the proper, if any, philosophy here? Shall one create a > new branch > > each time it is re integrated with the trunk? > > If you want to keep the branch alive, don't use --reintegrate. > > From the fine manual: > > "In Subversion 1.5, once a --reintegrate merge is done from branch > to > trunk, the branch is no longer usable for further work. It's not > able > to correctly absorb new trunk changes, nor can it be properly > reintegrated to trunk again. For this reason, if you want to keep > working on your feature branch, we recommend destroying it and then > re-creating it from the trunk" > > You will want to read > http://svnbook.red- > bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.a > dvanced.reintegratetwice > if you plan on using --reintegrate while keeping the branch around. Ff after you re-integrate you merge that rev from trunk with --record-only you can keep using the same branch. But, yes for the most part, "reintegrate" is designed for feature branches which are generally not used/needed after the feature is reintegrated into trunk. BOb
