Adding auto properties after file has been committed
I have a repository and just enabled/added some auto properties. How can I go back and add these properties to files already committed? I really don't want to do this manually and was hoping there was an automated method to do this. Thanks, Jeremy
Re: Subversion on AIX
On Oct 12, 2010, at 11:41 AM, David Weintraub wrote: > I do have gcc version 4.0.0, but I don't have the APR library. We > don't plan to use Apache httpd, but just svnserve instead. APR is needed by Subversion regardless of the network server used. > I downloaded the Universal AIX tarball (only 1.4, but I'd be happy > with anything now), and had problems since it was tarred up at the > root of the directory. I used pax to untar the file, so I could put it > under something besides /opts. The files are placed under /home/david. > > $ LIBPATH=/home/david/subversion/opt/subversion/lib:$LIBPATH You probably want a colon between the first two paths, although this won't help. > $ ./svn > exec(): 0509-036 Cannot load program ./svn because of the following errors: >0509-022 Cannot load module > /home/david/subversion/opt/subversion/lib/libsvn_client-1.so. >0509-150 Dependent module /opt/subversion/lib/libsvn_wc-1.so > could not be loaded. >0509-022 Cannot load module /opt/subversion/lib/libsvn_wc-1.so. >0509-026 System error: A file or directory in the path name > does not exist. >0509-022 Cannot load module svn. >0509-150 Dependent module > /home/david/subversion/opt/subversion/lib/libsvn_client-1.so could not > be loaded. >0509-022 Cannot load module . > > Any ideas at this point? Yes...the binary was built to be ran from /opt/subversion. Running anywhere else will fail miserably. Thank the AIX compiler/linker. There isn't much you can do without trying to use another binary or building it yourself. Take care, Jeremy Whitlock Twitter: jcscoobyrs Website: http://www.thoughtspark.org
sparse checkout tool
I remember reading about a tool that let you define what parts of a repository were needed to create a work space. It basically did a bunch of sparse checkouts based on a config file. Could someone remind me what was its name? Please reply directly as I'm no longer on the list. Thanks JLM
Directory pointing to wrong repository location
I'm using svn+ssh with my repository. I have it checked out in 2 locations. After some amount of time, the location becomes corrupted. But the both don't become corrupted at the same time, so I believe this is a client issue. If I run: svn status -u from the root checked-out dir I get: svn: No repository found in 'svn+ssh:///home/svn/repos' However, if I run svn info: Repository Root: svn+ssh:///home/svn/repos/adagogo_beta Repository UUID: Revision: 35 Node Kind: directory Schedule: normal Last Changed Author: jeremy Last Changed Rev: 35 Last Changed Date: 2011-01-28 16:27:49 -0800 (Fri, 28 Jan 2011) Note the svn info returns the correct repo path, but svn status -u is pointing to the server's repository's directory. In the .svn/entries file, I have these 2 lines, which I believe are correct: svn+ssh:///home/svn/repos/adagogo_beta/trunk svn+ssh:///home/svn/repos/adagogo_beta Like I said before, I have this in 2 directories, currently 1 works, the other doesn't (but won't in some time), so I believe this is a client issue. I'm wondering where the svn status -u command is finding that repository root. -- Jeremy McJunkin
Re: SVN and launchd
On Feb 9, 2011, at 1:47 PM, Bill Waggoner wrote: > Does someone have a sample launchd plist (10.6.5) for the svn daemon or can > point me to a source for one? I'd like to set it up as start-on-demand as > the SVN server is very lightly loaded. I've heard of people using this and being successful: http://codesnippets.joyent.com/posts/show/303 Take care, Jeremy Whitlock Twitter: jcscoobyrs Website: http://www.thoughtspark.org
Re: Worst Error Message?
On 30 Jul 2011, at 18:17, Les Mikesell wrote: > > '403 forbidden' makes reasonable sense for a client-side message to someone > who shouldn't know internal details anyway. Seriously? You think an HTTP response code (which *is* an internal detail) is an acceptable error message. You think it makes sense? Why is 403 forbidden? Oh, right, that's just a code. Ok what is forbidden? Is it me? the repository? writing to the repository? writing to a particular file? Why is it forbidden? Is it because it is Tuesday? WHY??? It's a useless error message. It's even pretty useless to the average person when they are trying to use a browser to access a URL. > Is something better in the apache error log where the sysadmin who set it up > wrong should be looking? Except that the administrator might not have set up the repository wrong. He might have made it deliberately read only. Users should not have to trawl Apache logs to find out that they are not allowed to commit to a repository. > > -- > Les Mikesell > lesmikes...@gmail.com >
Re: Worst Error Message?
On 30 Jul 2011, at 20:10, Les Mikesell wrote: > On 7/30/11 1:14 PM, Jeremy Pereira wrote: >> >> On 30 Jul 2011, at 18:17, Les Mikesell wrote: >> >>> >>> '403 forbidden' makes reasonable sense for a client-side message to someone >>> who shouldn't know internal details anyway. >> >> Seriously? You think an HTTP response code (which *is* an internal detail) >> is an acceptable error message. You think it makes sense? Why is 403 >> forbidden? Oh, right, that's just a code. Ok what is forbidden? Is it me? >> the repository? writing to the repository? writing to a particular file? >> Why is it forbidden? Is it because it is Tuesday? WHY??? >> >> It's a useless error message. It's even pretty useless to the average person >> when they are trying to use a browser to access a URL. > > From a security perspective it is a bad idea to tell a network client that is > doing something you have explicitly denied any of the details of how the > system is configured to prevent it. Working correctly is usually a yes or no > question and this answer is clearly 'no'. > From a software-that-is-not-a-complete-pig-to-use point of view, this is nonsense. If I'm a user trying to check something in to subversion, "403 forbidden" is useless. I don't know if I've got to the wrong server, mistyped a URL or don't have access rights. If you think the error message "you do not have permission to commit to $URL_THATS_EASY_TO_FIND_IN_THE_WORKING_COPY" is a security risk, you need to think again about what security is. >>> Is something better in the apache error log where the sysadmin who set it >>> up wrong should be looking? >> >> Except that the administrator might not have set up the repository wrong. >> He might have made it deliberately read only. Users should not have to >> trawl Apache logs to find out that they are not allowed to commit to a >> repository. > > Right, if the system is intentionally set up for read-only access, the user > should not get a hint about how to work around it, and it won't do them any > particular good to know if it is denied in the http config, the authorization > setup, or the filesystem. Really, what do you need to know as an end user > besides that your commit was denied? Telling somebody that they only have read access to a repository is not giving them a hint about how to work around it. "403 forbidden" is not telling somebody that they only have read access to a repository (or part of a repository). It's telling them that a web server somewhere doesn't like them. "What a web server? I thought I was using subversion" says the user.
Re: Worst Error Message?
On 31 Jul 2011, at 17:46, Rafael Heise wrote: > In my opinion, as a network administrator, I don't want to show to my end > users why the user shouldn't commit anything in the repository. In my opinion as a Subversion user, that sucks. I think I'll switch to Mercurial. Oh, no wait, the Subversion team agreed with me and changed the message. > Because as Les Mikesell said, the message could show someway to workaround > and allow the user to commit something without permission. If there *is* a work around, that is a security fail anyway. I hope, for your employers sake, you do not rely on security through obscurity. > I think the current message, 403-forbidden is a excellent message because > when the end user sees this message, the user needs to call me and ask why is > not possible to commit, and then I can explain that the folder, for that > user, is only for read. I think it is a terrible message, because, if I see "403 forbidden" I call the network admin to find out why the web server is broken. If I see "You do not have permission to commit to $URL" I call the configuration manager to apply to join the list of committers. Notwithstanding that the "403 forbidden" exposes a detail of implementation that you think could lead to a work around. > If he/she need to commit something to that folder, the user need to talk with > someone who has permission. Or ask for the administrator to change the > permissions. So where's the harm in telling them that in their native language rather than expecting them to understand HTTP response codes? > I guess a lot of users gets confuse about the sides, and as a lot of people > are both (user and administrator) they just think the messages should show in > the client-side "what is wrong" to fix it in the server, but the messages are > not to the client-side know how to fix in the server but just to let the > users know that they CAN NOT commit anything because they have no permission, > just it. > If a user is not meant to have permission to commit stuff to the repository, they certainly shouldn't have the necessary admin rights on the server to fix the problem.
Re: 1.7 neon fetched by get-deps.sh, but not usable by configure?
Hello all, I can confirm that Neon use to be built automatically by Subversion without specifying --with-neon if the Neon sources were within the Subversion sources directory. As of 1.7.0, this is no longer the case and I am now having to manually build/install Neon and then use the --with-neon configure flag. It's not a big deal but I too was surprised by this. -- Take care, Jeremy Whitlock http://www.thoughtspark.org
Setting auto properties after file(s) have been committed.
I just created some auto properties settings for my repository. I need to now apply these settings to all the files in my repository. Is there some automated way to do this or do I have to do it manually? Thanks, Jeremy
svn load command does not restore all files from dump
I am trying to move my repository from one server to another. I am doing this by dumping the repository and moving the dump file and then creating and loading a new repository on the new server. The trouble is on the new server, not all of the files are restored. The "svnadmin load Repo < dumpfile" command finishes (i.e. still shows up when I do 'ps -aux') yet the size of the repository folder is not increasing in size; no new data/files are being added. Can someone provide some assistance with this situation? Thanks, Jeremy
svn dump and load not preserving all files
I am migrating my repository to a new server. This requires that I dump the original and the create a new repository on the new server and use the svnadmin load command to import everything. I have been able to do this for a few of my repositories, but one in particular isn't working. The dump file for this repository is > 9 GB. The load command starts out, but never finishes. The size of my repository gets to 2.1 GB and then it seems to stop even though the svnadmin load command is still running. Eventually (> 24 hours) the command stops (finishes) but the size of my repository is only 2.1 GB when it should be around 9 GB. Also, not all of the files have been restored. Is there a limit in the size of a dump file that can be used? I would be surprised if that limit were around 9 GB. I'm sure there are repositories that are much larger than that. Any ideas on what could be wrong? Thanks, Jeremy
Re: svn dump and load not preserving all files
On Tue, Jan 19, 2010 at 1:05 PM, Thomas Loy wrote: > Which OS? Some operating systems have file size limits of 4 GB or less. > > Cheers, > > Tom Loy > The original OS was on a Mac, the new OS is some *nix server, probably Linux. I don't believe either of these have limitations as small as 4GB. Am I wrong? Thanks, Jeremy > > -Original Message- > From: Jeremy Conlin [mailto:jlcon...@gmail.com] > Sent: Tuesday, January 19, 2010 3:03 PM > To: users@subversion.apache.org > Subject: svn dump and load not preserving all files > > I am migrating my repository to a new server. This requires that I > dump the original and the create a new repository on the new server > and use the svnadmin load command to import everything. I have been > able to do this for a few of my repositories, but one in particular > isn't working. The dump file for this repository is > 9 GB. The load > command starts out, but never finishes. The size of my repository > gets to 2.1 GB and then it seems to stop even though the svnadmin load > command is still running. Eventually (> 24 hours) the command stops > (finishes) but the size of my repository is only 2.1 GB when it should > be around 9 GB. Also, not all of the files have been restored. > > Is there a limit in the size of a dump file that can be used? I would > be surprised if that limit were around 9 GB. I'm sure there are > repositories that are much larger than that. > > Any ideas on what could be wrong? > > Thanks, > Jeremy >
Re: svn dump and load not preserving all files
On Tue, Jan 19, 2010 at 1:05 PM, Mark Phippard wrote: > On Tue, Jan 19, 2010 at 3:03 PM, Jeremy Conlin wrote: >> I am migrating my repository to a new server. This requires that I >> dump the original and the create a new repository on the new server >> and use the svnadmin load command to import everything. I have been >> able to do this for a few of my repositories, but one in particular >> isn't working. The dump file for this repository is > 9 GB. The load >> command starts out, but never finishes. The size of my repository >> gets to 2.1 GB and then it seems to stop even though the svnadmin load >> command is still running. Eventually (> 24 hours) the command stops >> (finishes) but the size of my repository is only 2.1 GB when it should >> be around 9 GB. Also, not all of the files have been restored. >> >> Is there a limit in the size of a dump file that can be used? I would >> be surprised if that limit were around 9 GB. I'm sure there are >> repositories that are much larger than that. >> >> Any ideas on what could be wrong? > > Did you direct the svnadmin output to a file that you could tail and > look for problems? > > FWIW, the final size of the repository ought to be significantly > smaller than the dump file. I'd check for things like the final > number of revisions. If the command did not throw an error, it > probably worked. I did redirect the output to a text file. The command never throws an error, but never completes either. There should be 24 revisions in the repository, but when I check out from the new server, there is only 1, so something isn't working right. Jeremy
Re: svn dump and load not preserving all files
On Tue, Jan 19, 2010 at 1:27 PM, Mark Phippard wrote: > On Tue, Jan 19, 2010 at 3:21 PM, Jeremy Conlin wrote: >> On Tue, Jan 19, 2010 at 1:05 PM, Thomas Loy wrote: >>> Which OS? Some operating systems have file size limits of 4 GB or less. >>> >>> Cheers, >>> >>> Tom Loy >>> >> The original OS was on a Mac, the new OS is some *nix server, probably >> Linux. I don't believe either of these have limitations as small as >> 4GB. Am I wrong? > > I doubt any OS has a limit like that. What can have a limit is 32-bit > integers for file size. Typically if your SVN is compiled with APR > 1.x then it supports files > 2 GB and if it is compiled with APR 0.9.x > then it does not. > > I do not think this would be your problem anyway. The dump file is > streamed into svnadmin, so it does not see it as a 9GB file anyway. > And for the repository itself, it would only manifest as a problem if > you had a single revision that was 2 GB. Given that it is a dump > file, perhaps if a single file in the dump file was 2 GB it could be a > problem since the size would too big for it to process. > > Remember the limit is for a single file in the filesystem. For a > repository, that usually means the revision file, which means you > would need a revision this big. The entire repository could still > have a million revision that were 1.9 GB each and be fine. I do have about 16 files that are each a few hundred MB in size, but none (that I'm aware of) is over 1GB. All of the large files were originally committed in a single revision. Jeremy
Re: svn dump and load not preserving all files
On Tue, Jan 19, 2010 at 1:34 PM, Mark Phippard wrote: > On Tue, Jan 19, 2010 at 3:32 PM, Jeremy Conlin wrote: >> I did redirect the output to a text file. The command never throws an >> error, but never completes either. There should be 24 revisions in >> the repository, but when I check out from the new server, there is >> only 1, so something isn't working right. > > OK, definitely. > > And if your dump file is 9 GB with only 24 revisions, there is a good > chance the problem is the size of a single revision. Basically make > sure you are using SVN that was compiled against httpd 2.2/apr 1.x. > Yes this is most likely true. I have about 16 files that are a few hundred MB each and were all originally committed in the same revision. I don't own the server where I'm migrating to. What command can I run to determine what the compile options were? Thanks, Jeremy
Re: svn dump and load not preserving all files
On Tue, Jan 19, 2010 at 2:05 PM, Ryan Schmidt wrote: > > On Jan 19, 2010, at 14:38, Jeremy Conlin wrote: > >> On Tue, Jan 19, 2010 at 1:34 PM, Mark Phippard wrote >> >>> Basically make >>> sure you are using SVN that was compiled against httpd 2.2/apr 1.x. >> >> Yes this is most likely true. I have about 16 files that are a few >> hundred MB each and were all originally committed in the same >> revision. >> >> I don't own the server where I'm migrating to. What command can I run >> to determine what the compile options were? > > I'm not aware of a command you could run on the client that would get the > server to tell you. You'd have to run e.g. otool on the programs and > libraries that are on the server. If you don't have access, ask those who do > to do it for you. > > Disregard this message. I just realized that my new server only has svn 1.4.2 while my original was using 1.6. I'm sure that is the problem. I feel stupid that I didn't check this earlier. Thanks, Jeremy
Re: svn dump and load not preserving all files
On Tue, Jan 19, 2010 at 2:18 PM, Mark Phippard wrote: >> Disregard this message. I just realized that my new server only has >> svn 1.4.2 while my original was using 1.6. I'm sure that is the >> problem. I feel stupid that I didn't check this earlier. > > That should not be a problem in terms of moving a dump file between > them. 1.4 might not have some features you want, but it should still > load the file. I installed svn 1.6.6 in my home directory on the remote server and used it load the dump file and everything worked without any trouble. So either the original 1.4.2 on the server was missing some compile options or it was necessary to use 1.6.6. Things seem to be looking up now. Thanks everyone for their help. Jeremy
Re: Building SVN 1.6.5
> + echo '*** Finished regression tests on RA_SVN (SVN method) layer ***' > + echo '*** Running regression tests on RA_DAV (HTTP method) layer ***' > + make davautocheck CLEANUP=true FS_TYPE=bdb > Adding password for user jrandom > Adding password for user jconstant > Syntax error on line 14 of /root/rpms/build/subversion-1. > 6.5/subversion/tests/cmdline/httpd-20100122-123335/cfg: > Error:\tApache has not been designed to serve pages while\n\trunning as root. > There are known race conditions that\n\twill allow any local user to read > any file on the system.\n\tIf you still desire to serve pages as root > then\n\tadd -DBIG_SECURITY_HOLE to the CFLAGS env variable\n\tand then > rebuild the server.\n\tIt is strongly suggested that you instead modify the > User\n\tdirective in your httpd.conf file to list a non-root\n\tuser.\n > make[1]: *** [davautocheck] Error 1 > error: Bad exit status from /root/rpms/tmp/rpm-tmp.55381 (%build) > Bad exit status from /root/rpms/tmp/rpm-tmp.55381 (%build) > make: *** [build_rpm_files] Error 1 There is no need to double post. I already answered this exact same email on the dev list. Just in case you didn't get it, the error tells you the problem. You shouldn't run this as root. Jeremy Whitlock http://www.thoughtspark.org
Subversion 1.6.9 for OS X
Hi All, For those of you that do not use a package manager on OS X, I have built new binaries of Subversion 1.6.9 for OS X. The new binaries are available here: http://bit.ly/svn-osx Feel free to provide feedback in the svnbinaries forum mentioned in the ReadMe accompanied with the binary and displayed during the installation process. Jeremy Whitlock http://www.thoughtspark.org
Is it possible to restore respository from working copy?
Due to my idiocy, I have deleted my svn repositories. However, I do have working copies. Is it possible to restore some versioning information from my working copies to a new repository? Thanks, Jeremy
Re: Is it possible to restore respository from working copy?
On Wed, Mar 10, 2010 at 8:08 AM, Giulio Troccoli wrote: >> Due to my idiocy, I have deleted my svn repositories. >> However, I do have working copies. Is it possible to restore >> some versioning information from my working copies to a new >> repository? > > Unfortunately I don't think so. You can delete all the .svn directories and > then import everything into a new repository but you will lose all your > history I'm afraid. That's what I was afraid of, but I thought I would ask first. Thanks, Jeremy
format: Permission denied even when read permissions are set
I just created a new repository, and loaded it with some initial files. However when I go to checkout from my repository I get the following: $ svn checkout svn+ssh://jlcon...@myserver.com/path/to/repos/Repo CP Password: svn: Can't open file '/path/to/repos/Repo/format': Permission denied I can log via ssh to check on the permissions of format and this is what they are: $ ls -lh total 9.5K -rw-rw-r-- 1 jlconlin jlconlin 229 Mar 11 06:55 README.txt drwxrwxr-x 2 jlconlin jlconlin 5 Mar 11 06:55 conf drwxrwxr-x 2 jlconlin jlconlin 2 Mar 11 06:55 dav drwxrwsr-x 5 jlconlin jlconlin 10 Mar 11 06:56 db -rw-rw-r-- 1 jlconlin jlconlin 2 Mar 11 06:55 format drwxrwxr-x 2 jlconlin jlconlin 11 Mar 11 06:55 hooks drwxrwxr-x 2 jlconlin jlconlin 4 Mar 11 06:55 locks It seems clear to me that I have both read and write permissions for the 'format' file. When I log in, I can view the file and see that the format says '5'. Does anyone know what is going wrong here? Thanks, Jeremy
Re: format: Permission denied even when read permissions are set
On Thu, Mar 11, 2010 at 9:27 AM, David Weintraub wrote: > The way svn+ssh works is very strange. svnserve is executed by each > user that uses the svn+ssh protocol. That means that you have to make > sure that all of these users are in the same group, and that group has > read/write permission on the entire Subversion archive. Plus, you have > to set umask for each user, so when they create a new file in the > Subversion repository, it is read/writeable by everyone in the group. > > Take a look at the Tunneling Over SSH chapter in the Subversion on line book: > <http://bit.ly/c7gxv5>. Thanks for the reminder. Currently it is just one user (me) that is accessing this repository and I know I have access to the files and folder in the directory as I showed in an earlier email and because I can go inside and see everything. What else could be wrong? Thanks, Jeremy
Re: format: Permission denied even when read permissions are set
On Thu, Mar 11, 2010 at 10:22 AM, David Weintraub wrote: > On Thu, Mar 11, 2010 at 12:07 PM, Jeremy Conlin wrote: >> On Thu, Mar 11, 2010 at 9:27 AM, David Weintraub wrote: >> Thanks for the reminder. Currently it is just one user (me) that is >> accessing this repository and I know I have access to the files and >> folder in the directory as I showed in an earlier email and because I >> can go inside and see everything. What else could be wrong? > > Is this Subversion repository on your system or on another system? It > could very well be that when you login as SSH, you are not exactly the > user you think you are. > > Can you SSH directly into that system, check out your user ID and > verify that its the ID you think it is? Yes I can do this and I have verified that I am a member of the group that owns the files and folders of the repository. The owning group has read and write permissions. > > (Of course, you SHOULDN'T be able to SSH into the Subversion > repository because that would allow users to munge the repository > directly which they shouldn't be doing. But if you can, you can at > least verify that you are who you think you are.) How can you prevent this and still allow the users to read and write to the repository? Thanks, Jeremy
Expected format problem
I'll bet this is an oft asked question on this list. I'm getting the error: svn: Expected FS format '2'; found format '4' If I understand correctly, this means that my local version of svn differs from the remote version of svn. Is this right? I installed 1.6.9 today on both my local version and my remote version and got the above error. Is there something else that I missed here? Thanks, Jeremy local$ /opt/subversion/bin/svn --versionsvn, version 1.6.9 (r901367) compiled Jan 25 2010, 22:25:43 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme remote$ svn --version svn, version 1.6.9 (r901367) compiled Mar 15 2010, 13:27:12 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme
Re: Expected format problem
On Mon, Mar 15, 2010 at 6:06 PM, Ryan Schmidt wrote: > On Mar 15, 2010, at 16:12, Jeremy Conlin wrote: > >> I'll bet this is an oft asked question on this list. I'm getting the error: >> >> svn: Expected FS format '2'; found format '4' >> >> If I understand correctly, this means that my local version of svn >> differs from the remote version of svn. Is this right? > > No, it means the version of Subversion that is directly reading the > repository is older than the version of Subversion that created the > repository. > > "Directly reading" means probably the version of Subversion on the server, > assuming you are using a repository access protocol other than file:///. I am accessing the repository via svn+ssh. I think the problem is that I have some version in /usr/bin and another version in ~/usr/local/bin. When I'm logged in, the version used is ~/usr/local/bin and that is 1.6.9. The version in /usr/bin is 1.4.2. Is it possible that these versions are getting mixed up? Thanks, Jeremy
Re: Expected format problem
On Mon, Mar 15, 2010 at 9:12 PM, Ryan Schmidt wrote: > On Mar 15, 2010, at 22:09, Jeremy Conlin wrote: >> On Mon, Mar 15, 2010 at 6:06 PM, Ryan Schmidt wrote: >>> No, it means the version of Subversion that is directly reading the >>> repository is older than the version of Subversion that created the >>> repository. >>> >>> "Directly reading" means probably the version of Subversion on the server, >>> assuming you are using a repository access protocol other than file:///. >> >> I am accessing the repository via svn+ssh. I think the problem is >> that I have some version in /usr/bin and another version in >> ~/usr/local/bin. When I'm logged in, the version used is >> ~/usr/local/bin and that is 1.6.9. The version in /usr/bin is 1.4.2. >> Is it possible that these versions are getting mixed up? > > Absolutely. The PATH you've defined for use when you log in via ssh > interactively isn't necessarily the same PATH that will be used when > connecting via ssh non-interactively (such as when using svn+ssh). > > So what is the correct way to set the PATH? Jeremy
Re: SVN 1.4.6 support exit codes
> > does SVN support exit codes. Suppose if I use "svn merge" in my shell script, > will svn be able to return exit code "0" if the merge is successful. Yes, Subversion's exit codes conform to Unix standards in that regard. All this time waiting around and you could had just run a simple test to get the answer. Jeremy Whitlock http://www.thoughtspark.org
Re: @ the turkey who compiled OSX svn 1.6 with hardcoded path of /opt/subversion...
> On Mar 24, 2010, at 20:56, Matt Harrison wrote: > >> ...please don't do that again. >> >> is it asking too much to choose where to install it? or at least using >> something standard like /usr/local with soft links into /usr/local/bin? > Well, that turkey is me. There are actually a few things to discuss here so we might as well go ahead and address each: 1) My Subversion builds are not custom. They use Subversion build scripts, untouched I might add, and the OS X tooling I use is also untouched. Any unsatisfactory result of this is not the cause of "the turkey" but of the tooling. I too have been biten by this or wanted to change it so that hardcoded paths at least would be relative instead of absolute but things are they way they are. I'm not sure of the problems they are causing you but if you would share, I'm sure I'm competent enough to fix them. 2) The reason I chose /opt/subversion instead of the "standard" locations is a simple one: There are many different ways to install Subversion and I wanted to install somewhere that is not going to interfere with other distributions. A perfect example of this is installing my binary and SCPlugin. If I adhere to the /usr/local "standard", both tools would have issues as they install their shared libraries to the same place. Being a Subversion committer, and not just some CollabNet drone on the payroll, I also was trying to make it so you could have my binary installed and it not interfere with the Subversion development I was doing. /opt is a standard location on Unix platforms to install optional software, which Subversion is. 3) My work on maintaining the OS X binary is not a CollabNet thing. I don't get paid for it, I've gotten no kick backs/bonuses or anything like that. I started doing this when there was a need and to this day it's still the most complete package you can find without using a package manager. Sure, I host it on CollabNet's site as a win-win for them and me. (The win for me is I don't have to worry about my web hosting plan running out of bandwidth and the win for CollabNet is they get some publicity from it.) I am solely responsible for the binary and CollabNet has no involvement in it other than the hosting of the downloads. 4) My build process is in the open and finding the build script would be easy had you read anything in the installer. That being said, being the only person involved with this and having no support/QA or anything like that, it's more than possible that I could have a flaw in my build process. I've not see anything to that effect and neither has anyone that's reached out to me. (Yes, I've had to explain the /opt vs. other standards a few times but in most cases, people understand why when I explain it.) The best part about this is I do all of this IN THE OPEN. Feel free to see the script at http://svnbinaries.open.collab.net, again just like is mentioned in the installer documentation. Those things being said, if you'd like to contribute or make formal requests about the binary, you now know I'm the guy to reach out to. (Again, had you read anything in the installer you would had seen my direct email and wouldn't of had to name call.) Having problems with the binary is one thing but the approach you took to voice your complains were pretty childish. It's people like you that make generous people like myself question why they even bother. -- Take care, Jeremy Whitlock http://www.thoughtspark.org
Re: @ the turkey who compiled OSX svn 1.6 with hardcoded path of /opt/subversion...
> 1st, thank you Jeremy! No problem. Out of the thousands of people that download the binary, to have only a handful of complaints isn't bad. ;) > 2nd, from a sysadmin perspective, I appreciate that the installation > process doesn't presume to know where everything goes. Having one > complete install structure has several advantage, like seeing how big it > is. I simply created links to the binaries in > /opt/CollabNet_Subversion/bin, in my preferred binary path, /usr/bin/. I agree. When I first shipped the binary I used /usr/local but for me to maintain an uninstallation script was a nightmare because of all of the files in /usr/local that might not be related to my binary, like the dependencies and such. I think there are many benefits to having the binary in a single, isolated location instead of being co-mingled with other softwares. In the end, I stand behind my reasoning. To each his/her own I guess. > 3rd, If your OS uses something like rpm, (Linux RH4 in my case), I used > the --relocate function to put the binaries in /usr/bin (on my desktop). I thought about that as well, having the installer allow you to choose where to install and having a script ran during the installation that would relocate. I already have the script done, since it's part of my build process. I just have never had anyone ask for such a thing. Most times, I explain my reasoning and people agree, or at least they don't bring it up again. Thanks for the feedback. -- Take care, Jeremy Whitlock http://www.thoughtspark.org
subscribing
I'm having trouble subscribing. if there's a trick please let me know. I sent mail to users-subscribe with just 'subscribe j...@zeevee.com' in the body no answer. We use a lot of project branches, that is, we branch from trunk, develop a feature and then merge it back to trunk. Quite often, we need to merge a change or two from trunk out to our branch along the way. What I have noticed is that when I go to merge the branch back to trunk, the changes that were merged from trunk to the branch are included when I do a 'svn mergeinfo --show-revs eligible '. Why is this? Shouldn't the system know that these were merged out and therefore do not need to be merged in? I do not ever use 'ignore-ancestry'. I end up doing a lot of 'svn merge --record-only's to block the reverse merges. Please reply directly as I do not seem to be able to subscribe. Thanks, JLM
mergeinfo and reintegrate
> > We use a lot of project branches, that is, we branch from trunk, > > develop a feature and then merge it back to trunk. Quite often, we need > > to merge a change or two from trunk out to our branch along the way. > > What I have noticed is that when I go to merge the branch back to trunk, > > the changes that were merged from trunk to the branch are included when > > I do a 'svn mergeinfo --show-revs eligible '. Why is > > this? Shouldn't the system know that these were merged out and therefore > > do not need to be merged in? I do not ever use 'ignore-ancestry'. > > > > I end up doing a lot of 'svn merge --record-only's to block the reverse > > merges. > > If you have a feature branch you should be merging from trunk into the branch regularly. then > when you are done with the feature you would do a reintegrate merge back. I don't see an > argument on merginfo to specify that you want to do a re-integrate. > Svn help mergeinfo does not reference --reintegrate at all. Are you saying that a merge with the -reintegrate option may skip some items that mergeinfo lists as eligible? Also the help for reintegrate says that the only difference is that it treats the merge as a lump sum, not as a sequence of mini merges. Are you saying that if you have done a complete merge out, you can skip the individual merge ins and just do one big reintegrate? If so, Is doing a complete merge out first mandatory? (I would think so). Can this model handle files that were deleted and re-added? Actually, now that I have written and reread this, I think I answered my own question. Using reintegrate is orthogonal to using mergeinfo. You use mergeinfo to pick up changes that have been made in a release branch that need to be merged to trunk, and you use -reintegrate to merge a project branch back to its baseline. I feel like I must have missed that section in the book. Is this not documented? Thanks JLM
RE: Automatic upgrade of wc format annoying on shared drives
I second that. I support fedora 7, 8, 9, 10, 11 (and soon 12), various ubuntu releases, plus windows XP, Vista, and Win7, and Mac OS 10.4, 10.5. When one of them upgrades, it causes me to scramble to build and deploy upgrades to the others. JLM -Original Message- From: Simon [mailto:tzueskj...@snkmail.com] Sent: Mon 4/12/2010 9:17 PM To: users@subversion.apache.org Subject: Automatic upgrade of wc format annoying on shared drives We have work directories shared between many physical machines here (via sshfs, nfs, etc). We also use subversion as our configuration management system for source files. When a newer client ends up on on of the work machines, it automatically (and silently) upgrades the wc metadata format of any working copies it touches. This prevents future access of any of the other clients until the working copies are manually downgraded (such as via: http://subversion.apache.org/faq.html#working-copy-format-change ). This is quite annoying. I think correct behaviour here is that the client should at least prompt the user to ask if it should upgrade the wc metadata format before messing with the working copy. Failing that, is there some way of locking a working copy to a particular version of the wc metadata format. Regards, Simon
RE: Automatic upgrade of wc format annoying on shared drives
> Jeremy Mordkoff wrote: > > I second that. I support fedora 7, 8, 9, 10, 11 (and soon 12), various > > ubuntu releases, plus windows XP, Vista, and Win7, and Mac OS 10.4, > > 10.5. When one of them upgrades, it causes me to scramble to build and > > deploy upgrades to the others. > > > > But working copies should really be disposable. As long as you keep your > changes commited, if the format is a problem for a different client, just delete > it and let that client build what it wants. > > -- >Les Mikesell > lesmikes...@gmail.com Our product also supports that variety of platforms. I request that changes be tested on all platforms before the changes are committed. That requires the engineer to either use a project branch or access a view from multiple machines. Since some machines are shared, sometimes views get inadvertently upgraded. Thanks Daniel. JLM
RE: Automatic upgrade of wc format annoying on shared drives
Jeremy Mordkoff wrote: >>> I second that. I support fedora 7, 8, 9, 10, 11 (and soon 12), > various >>> ubuntu releases, plus windows XP, Vista, and Win7, and Mac OS 10.4, >>> 10.5. When one of them upgrades, it causes me to scramble to build > and >>> deploy upgrades to the others. >>> >> But working copies should really be disposable. As long as you keep > your >> changes commited, if the format is a problem for a different client, > just delete >> it and let that client build what it wants. >> > > Our product also supports that variety of platforms. I request that > changes be tested on all platforms before the changes are committed. > That requires the engineer to either use a project branch or access a > view from multiple machines. Since some machines are shared, sometimes > views get inadvertently upgraded. > And you are not concerned that some uncommitted change in this working copy might be the thing that makes all your tests pass? I like to make 'svn checkout' or 'update' the only means to get the source to the testing platforms to ensure that the test is of a reproducible state. -- Les Mikesell lesmikes...@gmail.com Absolutely. We use svn:ignore and svn status to make it easy to make sure such things don't happen. And then we also have a QA group (this is for developer testing). I can't say they always adhere to it, but that can't say that their tools don't support it. jlm
RE: Unable to checkout files: Can't open file: Permission denied
did you mean chmod -R 770 myrepository ? -Original Message- From: Disc Magnet [mailto:discmag...@gmail.com] Sent: Tue 4/13/2010 5:27 PM To: Erik Andersson Cc: users@subversion.apache.org Subject: Re: Unable to checkout files: Can't open file: Permission denied I did that. I ran these two commands. chgrp -R www-data myrepository chown -R 770 myrepository Now, I get this error: $ svn commit -m "Updating" svn: Commit failed (details follow): svn: Could not open the requested SVN filesystem Please help. On Wed, Apr 14, 2010 at 1:59 AM, Erik Andersson wrote: > The user running apache needs write access to your repository. > Cheers / Erik > > On Tue, Apr 13, 2010 at 10:01 PM, Disc Magnet wrote: >> >> This is my configuration. >> >> >> DAV svn >> SVNParentPath /home/magnet/myrepository/ >> >> >> The checkout command runs fine: >> >> svn co http://localhost/myrepository/hachumachu >> >> However, the commit command results in this error: >> >> mag...@faku:~/hachumachu$ svn commit -m "Additional line" >> svn: Commit failed (details follow): >> svn: Can't open file >> '/home/magnet/myrepository/hachumachu/db/txn-current-lock': Permission >> denied >> >> This appears in my Apache error log: >> >> [Wed Apr 14 01:04:58 2010] [error] [client 127.0.1.1] Could not create >> activity >> /myrepository/hachumachu/!svn/act/a3cb143e-3098-499b-b7d1-5d5b7e982881. >> [500, #0] >> [Wed Apr 14 01:04:58 2010] [error] [client 127.0.1.1] could not begin >> a transaction [500, #13] >> [Wed Apr 14 01:04:58 2010] [error] [client 127.0.1.1] Can't open file >> '/home/magnet/myrepository/hachumachu/db/txn-current-lock': Permission >> denied [500, #13] >> >> In case you want to see the permissions on the folders. >> >> mag...@faku:~/myrepository$ ls -l >> total 12 >> drwxr-xr-x 4 magnet magnet 4096 2010-04-11 18:13 ondalabondala >> drwxr-xr-x 6 magnet magnet 4096 2010-04-11 18:12 hachumachu >> drwxr-xr-x 6 magnet magnet 4096 2010-04-11 19:36 haggupaggu >> >> Please help. > >
Re: svn+ssh: Expected FS format '2'; found format '4'
I recently had the same problem. I never quite got it figured out, but you may have more success than I did. The important emails can be found here: http://mail-archives.apache.org/mod_mbox/subversion-users/201003.mbox/%3c2588da421003151412p115d5f3fo4324170d8b553...@mail.gmail.com%3e Jeremy On Sat, Apr 17, 2010 at 8:58 AM, Rainer Dorsch wrote: > Hello, > > I tried to checkout from a server via svn+ssh: > > r...@blackbox:~/Managed/Daten$ svn checkout > svn+ssh://rdor...@hdcl037/var/svn/OSSM/svn-repository/trunk OSSM > > Enter passphrase for key '/home/rd/.ssh/id_rsa': > rdor...@hdcl037's password: > svn: Expected FS format '2'; found format '4' > r...@blackbox:~/Managed/Daten$ > > I think the problem is that on the server there is a default installation of > svn: > > hdcl037: rdorsch $ svn --version > svn, version 1.4.2 (r22196) > compiled Nov 20 2006, 07:17:37 > > Copyright (C) 2000-2006 CollabNet. > Subversion is open source software, see http://subversion.tigris.org/ > This product includes software developed by CollabNet > (http://www.Collab.Net/). > > The following repository access (RA) modules are available: > > * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol. > - handles 'http' scheme > - handles 'https' scheme > * ra_svn : Module for accessing a repository using the svn network protocol. > - handles 'svn' scheme > * ra_local : Module for accessing a repository on local disk. > - handles 'file' scheme > > hdcl037: rdorsch $ > > and a more recent version in a non-standard dir (which is added to my path > in .bash_profile) > > hdcl037: rdorsch $ svn --version > svn, version 1.6.9 (r901367) > compiled Apr 16 2010, 15:19:25 > > Copyright (C) 2000-2009 CollabNet. > Subversion is open source software, see http://subversion.tigris.org/ > This product includes software developed by CollabNet > (http://www.Collab.Net/). > > The following repository access (RA) modules are available: > > * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. > - handles 'http' scheme > * ra_svn : Module for accessing a repository using the svn network protocol. > - with Cyrus SASL authentication > - handles 'svn' scheme > * ra_local : Module for accessing a repository on local disk. > - handles 'file' scheme > * ra_serf : Module for accessing a repository via WebDAV protocol using serf. > - handles 'http' scheme > - handles 'https' scheme > > hdcl037: rdorsch $ > > I expect that .bash_profile is not executed when I do svn+ssh, but it is when > I do ssh into the host regularly. > > I have now root access to the server containing the repository, I cannot use > keypair authentification. > > Any suggestions are welcome. > > Thanks, > Rainer > > -- > Rainer Dorsch > Lärchenstr. 6 > D-72135 Dettenhausen > 07157-734133 > email: rdor...@web.de > jabber: rdor...@jabber.org > GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E > Full GPG key: http://pgp.mit.edu/ >
blocking merges and branches
I have two special files. One I would like never to be merged. The other I would like to only ever exist in trunk. Is there any mechanism to accomplish this? If you careThe file I don't want to merge contains the version numbers for products built in that branch and the un-branchable file is a list of branches that I only want to have in trunk. Currently I do a merge --record-only for the former and live with the latter. JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
How to speed up subversion
I have a working copy/respository with many files that are several hundred MB each. Whenever I try to check the status of my working copy or do a commit, it can take a long time (~1 min) before I get a response. I don't have any externals and the number of total files in my repository is ~100. Has anyone else experienced this or knows how to speed things up? I'm running svn 1.6.5 on Mac OSX 10.6.2. Thanks, Jeremy
Re: How to speed up subversion
On Wed, Apr 21, 2010 at 9:58 AM, Les Mikesell wrote: > On 4/21/2010 10:48 AM, Jeremy Conlin wrote: >> >> I have a working copy/respository with many files that are several >> hundred MB each. Whenever I try to check the status of my working >> copy or do a commit, it can take a long time (~1 min) before I get a >> response. I don't have any externals and the number of total files in >> my repository is ~100. Has anyone else experienced this or knows how >> to speed things up? I'm running svn 1.6.5 on Mac OSX 10.6.2. > > What client-server protocol are you using? This could be a problem with DNS > or the authentication method besides whatever svn has to do. I am using svn+ssh. I have several other repositories located on the same server. These repositories are smaller in the number of MB and they also have no speed issues as I have with the "big" one. Jeremy
RE: Merging a Revision back to the trunk
What command did you use? When was the branch created? At rev 226? jlm Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com > -Original Message- > From: Georg Heisenberger [mailto:heissenberger.ge...@gmx.at] > Sent: Thursday, April 22, 2010 1:13 PM > To: users@subversion.apache.org > Subject: Merging a Revision back to the trunk > > Hi everybody! > > I’ve got a question about merging a revision of an > feature- branch back to the trunk. > Sounds quiet simple: > - Select the branch > - The revision > > ⇒ The changes made in the specific revision should be > applied on my working copy (trunk) > > The “problem” (at least I don’t understand why it’s happening) > is that subversion is merging more than one revision. > > In my case I only want revision 278. > The response of subversion is, that it starts with revision 226 > > > The result: I’ve got more things merged to my WC than I wanted to > > I would be glad, if some can tell me, why that is happening > > Georg >
tracking merges
I know how to find what has been merged into any branch, but is there a tool to track where changes have been merged to? Here's my problem. I was working on a customer release based on rev 5 of our product. Now they have decided to use rev 4 instead. So I need to merge a bunch of changes from the rev 5 branch to the rev 4 branch...actually a new branch based on rev 4. But only their customizations. What I would really like is an option to svn log that would tell me every branch to which each change had been merged, but I'm thinking I'll have to run reports against the potential merge destinations first and then post process the svn log output. Anyone already tackled this? I wish I had just done their customizations in a branch. Thanks JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
RE: Is svn branching too difficult?
Branching and merging is not the simplest operation in the world. Svn is one of the easier environments for doing merging. (a) doing test merges is easy (b) creating branches is easy and quick (c) it does have merge tracking If you had not gotten the 101 property changes, what would your opinion be? Do you have any idea where these property changes came from? JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com > -Original Message- > From: David Aldrich [mailto:david.aldr...@eu.nec.com] > Sent: Tuesday, May 18, 2010 9:55 AM > To: users@subversion.apache.org > Subject: Is svn branching too difficult? > > Hi > > I have just finished working on a branch and have performed a reintegrate merge back into the > trunk. I only worked on 4 files in the branch and I carefully merged from trunk to branch > several times (including immediately prior to the reintegration). > > The reintegration correctly identified the four files that I had worked on and that had > changed, but also showed 101 files as 'Modified (properties only)'. I know that there are > good documents that describe merging and explain what this sort of state means, but I > struggle to understand what is going on during merging sometimes. > > I feel unable to recommend branching to my colleagues, it just seems too complicated. I don't > think they would have the time or patience to understand the nuances of merging. > > Do other people feel the same way? Is svn branching too difficult? > > (I am using svn server 1.5.5 and the 1.6.11 client. I wonder if things will be better when we > upgrade the server?) > > This is not meant as a complaint, I am simply trying to judge whether svn branching is > workable. > > With best regards > > David
RE: Is svn branching too difficult?
My rules of thumb for merging (a) always use a fully populated workspace (b) always merge from the top By following these rules, I only get mergeinfo properties in the tops of my workspaces. JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com > -Original Message- > From: Cufi, Carles [mailto:carles.c...@nordicsemi.no] > Sent: Tuesday, May 18, 2010 10:16 AM > To: Mark Phippard; David Aldrich > Cc: users@subversion.apache.org > Subject: RE: Is svn branching too difficult? > > Hi there, > > > Subversion is likely working properly, but yes it is confusing. When > > you do a merge into a branch, Subversion updates its mergeinfo > > tracking on all of the locations that have the property set. There > > have been numerous posts that describe how and why it gets set in the > > first place. > > Thanks for the info. As I described in an earlier post, I have a trunk and a branch > completely clean of svn:mergeinfo properties and then when I update my branch with the latest > trunk a bunch of svn:mergeinfo properties get added to a sparse set of files. All the posts I > have read ask people to cleanup all svn:mergeinfo in the trunk and then start branching from > it. I have done so but the properties keep reappearing, and this is really confusing for me. > > > Because it is confusing, we have changed how Subversion works in the > > next release. It will not update paths that were not modified by the > > merge, and then Subversion was modified to handle the fact that these > > paths do not get their merge tracking information updated. > > Excellent! Looking forward to that! > > Thanks! > > Carles
detecting merge outs
Here's the situation. We have a release branch that has been around way too long. At one point we did a release from it and around that time it was merged to trunk. There are about 100 commits to it since then. Some were merge outs from trunk, some were changes made directly in the branch. Some of these were merged to trunk, but some were not. Now I need to integrate trunk with the branch. My choices are to merge out from trunk, resolve conflicts and then merge -reintegrate back to trunk, or just merge from the branch to trunk and be done. I am leaning towards the latter. Will the merge outs (from trunk to the branch) cause a problem when I try to merge back in? Does anyone have any advice besides making sure I do the merges in chronological order? JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
RE: How to speed up subversion
On 5/24/2010 3:51 PM, David Brodbeck wrote: > > On May 21, 2010, at 8:23 AM, Hyrum K. Wright wrote: >> Actually, Subversion is a bit more intelligent about it, attempting to use >> modification times and sizes, before doing a byte-by-byte comparison. > > Even that can be slow if there are lots of files involved. Note that some > filesystems have particularly bad performance if there are lots of files in a > single directory, as well. This is especially true of NFS. In one extreme > example, I've seen a simple "ls" take tens of minutes to produce any output > in an NFS-mounted directory with ~1,000,000 files. But to be fair, note that ls sorts its output, so it can't output anything until it has read everything. -- Les Mikesell lesmikes...@gmail.com JLM>> unless you use the raw option
Re: Downgrade repository's version (1.4->1.3) without losing local modifications
> There is a script floating around somewhere that will do it. http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/change-svn-wc-format.py But as you'll see, it only works with 1.4+. Take care, Jeremy Whitlock Twitter: jcscoobyrs Website: http://www.thoughtspark.org
RE: Merging branch back to trunk omits dirs and files that were added in the branch
Sounds like the target directories already existed in trunk. How did they get created? JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com <mailto:j...@zeevee.com> www.zeevee.com <http://www.zeevee.com/> From: Dean Schulze [mailto:dean_w_schu...@yahoo.com] Sent: Tuesday, June 01, 2010 2:48 PM To: users@subversion.apache.org Subject: Merging branch back to trunk omits dirs and files that were added in the branch I've tried this with both TortoiseSVN and the merge tool that comes with Subclipse. I've added subdirectories with files under several directories on the branch (along with many other changes). When I merge back to the trunk the top level directories under which I added the subdirectories and files show up as tree conflicts. None of the sub-directories or files show up. I mark the tree conflicts as resolved (I mark all tree conflicts as resolved choosing the repository / branch file whenever asked to resolve manually). In the merged trunk the new subdirectories and files are missing all together. The trunk svn:mergeinfo shows the correct range of revisions. What do I have to do to simply merge the branch back to the trunk? Firstly, this is not a conflict of any kind. I added those directories and files intentionally. Secondly, ever since tree conflicts were added to svn I've found svn to be completely unreliable when it comes to merging. How do I turn off tree conflicts (eliminate them all together)? What do I have to do to get back to reliable merging, switch to git?
RE: multiple ssh connections
Another option is to establish a single SSH session using port mapping and then run all of your SVN traffic across that. Something like ssh -L 3690:svn_server:3690 ssh_server svn svn://localhost/ The first line says take any traffic destined for the svn port on my machine and send it to the svn port on the svn server at the other end of an SSH tunnel. The second line says pretend my svn server is local JLm
Possible bug in svn's gnome-keyring support?
Hi, I noticed after updating svn to version 1.6.6 that svn now has gnome-keyring support. However It seems to ignore the --username --password flags if that support is enabled. I don't use the gnome-keyring or even gnome but subversion refused to let me commit until I turned off password-stores in the config despite giving it a valid username and password. Instead it would prompt for the gnome-keyring password which is not set up for me and refuse to continue until I successfully authenticated to the keyring. This seems like the wrong behavior to me. Is it intended? Here is my subversion information: svn, version 1.6.6 (r40053) compiled Dec 12 2009, 05:06:12 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet ( http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme Jeremy
Re: Possible bug in svn's gnome-keyring support?
The strangeness is it's insistence on using the Gnome Keyring despite me not using Gnome. Is this the expected default behaviour? On Tue, Jul 13, 2010 at 11:08 AM, Varnau, Steve (Neoview) < steve.var...@hp.com> wrote: > Jeremy, > > > > If svn is configured to use a Gnome keyring, then it is trying to store the > password you are giving on the command line in the keyring. Hence it is > prompting for the gnome-keyring password. If you also specify > –no-auth-cache, then you might not get a prompt. > > > > -Steve > > > > *From:* Jeremy Wall [mailto:jw...@google.com] > *Sent:* Tuesday, July 13, 2010 8:09 AM > *To:* users@subversion.apache.org > *Subject:* Possible bug in svn's gnome-keyring support? > > > > Hi, > > > > I noticed after updating svn to version 1.6.6 that svn now has > gnome-keyring support. > > > > However It seems to ignore the --username --password flags if that support > is enabled. I don't use the gnome-keyring or even gnome but subversion > refused to let me commit until I turned off password-stores in the config > despite giving it a valid username and password. Instead it would prompt for > the gnome-keyring password which is not set up for me and refuse to continue > until I successfully authenticated to the keyring. > > > > This seems like the wrong behavior to me. Is it intended? > > > > Here is my subversion information: > > > > svn, version 1.6.6 (r40053) > >compiled Dec 12 2009, 05:06:12 > > > > Copyright (C) 2000-2009 CollabNet. > > Subversion is open source software, see http://subversion.tigris.org/ > > This product includes software developed by CollabNet ( > http://www.Collab.Net/). > > > > The following repository access (RA) modules are available: > > > > * ra_neon : Module for accessing a repository via WebDAV protocol using > Neon. > > - handles 'http' scheme > > - handles 'https' scheme > > * ra_svn : Module for accessing a repository using the svn network > protocol. > > - with Cyrus SASL authentication > > - handles 'svn' scheme > > * ra_local : Module for accessing a repository on local disk. > > - handles 'file' scheme > > > > > > Jeremy >
Re: Possible bug in svn's gnome-keyring support?
There was no password-stores line in my config file. I had to add a password-stores line to the file to disable it. Is there a second config file it might be pulling from that I'm unaware of? On Tue, Jul 13, 2010 at 11:15 AM, Varnau, Steve (Neoview) < steve.var...@hp.com> wrote: > It should only use gnome if it is specified in your config file > (~/.subversion/config): > > > > password-stores = gnome-keyring > > > > -Steve > > > > *From:* Jeremy Wall [mailto:jw...@google.com] > *Sent:* Tuesday, July 13, 2010 9:11 AM > *To:* Varnau, Steve (Neoview) > *Cc:* users@subversion.apache.org > *Subject:* Re: Possible bug in svn's gnome-keyring support? > > > > The strangeness is it's insistence on using the Gnome Keyring despite me > not using Gnome. Is this the expected default behaviour? > > On Tue, Jul 13, 2010 at 11:08 AM, Varnau, Steve (Neoview) < > steve.var...@hp.com> wrote: > > Jeremy, > > > > If svn is configured to use a Gnome keyring, then it is trying to store the > password you are giving on the command line in the keyring. Hence it is > prompting for the gnome-keyring password. If you also specify > –no-auth-cache, then you might not get a prompt. > > > > -Steve > > > > *From:* Jeremy Wall [mailto:jw...@google.com] > *Sent:* Tuesday, July 13, 2010 8:09 AM > *To:* users@subversion.apache.org > *Subject:* Possible bug in svn's gnome-keyring support? > > > > Hi, > > > > I noticed after updating svn to version 1.6.6 that svn now has > gnome-keyring support. > > > > However It seems to ignore the --username --password flags if that support > is enabled. I don't use the gnome-keyring or even gnome but subversion > refused to let me commit until I turned off password-stores in the config > despite giving it a valid username and password. Instead it would prompt for > the gnome-keyring password which is not set up for me and refuse to continue > until I successfully authenticated to the keyring. > > > > This seems like the wrong behavior to me. Is it intended? > > > > Here is my subversion information: > > > > svn, version 1.6.6 (r40053) > >compiled Dec 12 2009, 05:06:12 > > > > Copyright (C) 2000-2009 CollabNet. > > Subversion is open source software, see http://subversion.tigris.org/ > > This product includes software developed by CollabNet ( > http://www.Collab.Net/). > > > > The following repository access (RA) modules are available: > > > > * ra_neon : Module for accessing a repository via WebDAV protocol using > Neon. > > - handles 'http' scheme > > - handles 'https' scheme > > * ra_svn : Module for accessing a repository using the svn network > protocol. > > - with Cyrus SASL authentication > > - handles 'svn' scheme > > * ra_local : Module for accessing a repository on local disk. > > - handles 'file' scheme > > > > > > Jeremy > > >
time since last checkin
Anyone got a quick and dirty way to determine how long ago was the last commit? I want to change my build system to not start a build if there was a very recent checkin. That way if someone is checking in a group of changes, I don't end up kicking off a build in the middle and then having to wait for a second build to get the full set of changes. I know most things should be checked in all at once so that they become one change set, but sometimes people have layers of changes and they like to check in the independent part first. Please reply directly...I'm off the list at the moment. jlm Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
trunk listed in svn:mergeinfo in trunk
Why would trunk be listed in the svn:mergeinfo in trunk? We've been using mergeinfo's for a while now. Could this be the result of merging out (from trunk to a project branch) and then back? Can this safely be deleted? I'm trying to clean up our mergeinfo's because they exist in too many directories and they contain references to literally 2 dozen branches that are long retired and I think they're slowing down my merges which now take almost 5 minutes each. jlm please cc me as I'm still off list
another mergeinfo question
I have two instances of mergeinfos in the root of my tree showing a wider range of changes merged in than a merge info in a subdirectory. Does svn merge these merge infos together? Example Mergeinfo in /zcode/trunk shows that /zcode/branches/rel_2:1124-1406 was merged Mergeinfo in /zcode/trunk/lcast shows that /zcode/branches/rel_2/lcast:1124-1388 was merged So was 1389-1406 merged in the lcast directory or not? No, I don't know how I got into this state. I wish I had caught this sooner, but rel_2 has been dormant for a while. I suppose I could look at the history of the property. I'm on list now JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
svndumpfilter and subtrees
I have a repository with multiple projects that used to be branched in parallel, but now need to be split. How do I accomplish this? Current tree zcode/ zcode/trunk/comp1 zcode/trunk/comp2 zcode/branches zcode/branches/rel_1/comp1 zcode/branches/rel_1/comp2 zcode/branches/rel_2/comp1 zcode/branches/rel_2/comp2 except there are actually 11 components, with 8 staying and 3 migrating to a new repository, and there are actually about 25 branches. There are 14,000 commits in our repository. One option (I think) would be to move comp2 to the top using a perl script against the svn dumpfile so that the tree became zcode/ zcode/trunk/comp1 zcode/branches zcode/branches/rel_1/comp1 zcode/branches/rel_2/comp1 ccode/ ccode/trunk ccode/trunk/comp2 ccode/branches ccode/branches/rel_1/comp2 ccode/branches/rel_2/comp2 And then filter on zcode vs ccode: svnadmin create repos/ccode svnadmin dump repos/zcode | perl -p -e 's-Nodepath: zcode/(trunk|(branches|tags)/[^/]+)/comp2-Nodepath: ccode/$1/comp2-;' | svndumpfilter include ccode | svnadmin load repos/ccode svnadmin create repos/zcode2 svnadmin dump repos/zcode | perl -p -e 's-Nodepath: zcode/(trunk|(branches|tags)/[^/]+)/comp2-Nodepath: ccode/$1/comp2-;' | svndumpfilter exclude ccode | svnadmin load repos/zcode2 My concern here is how do directories like /ccode/trunk and /ccode/branches get created? Can a pre-create them in the new repository? I don't care that much about preserving revision numbers in the ccode repo. I cannot simply clone the repos and then selectively delete as the new owners of the new repo could potentially recreate the code from the old repo. Are there any other options? JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com <mailto:j...@zeevee.com> www.zeevee.com <http://www.zeevee.com/>
RE: commit fails with "has no ancestry information" error (solved)
Thanks for taking the time to post this. JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com > -Original Message- > From: Neil Brewster [mailto:n...@ajmani.org] On Behalf Of Neil Brewster > Sent: Thursday, August 26, 2010 10:21 AM > To: users@subversion.apache.org > Subject: commit fails with "has no ancestry information" error (solved) > > I've seen this issue reported in various mailing lists without solutions > (including the 2006 archives of this list!). Recently I found an answer > and wanted to add it to the mailing list archives: > > Problem: > > > % svn commit -m '' > > > > I get the following error: > > > > > > svn: '/d0/home/tlm/path_to_some_dir/Project' has no > > ancestry information > > Resolution - > From http://victorhurdugaci.com/svn-no-ancestry-information/: > > It seems that the SVN commit is forbidden if you try to commit a file > that is a folders structure, and one of the nodes in it (not the top most > parent) is missing the .svn folder. > > - folder1 [with .svn] > - folder2 [without .svn] > - folder3 [with .svn] > Committing “folder3″ will bring that error message. > > In my case, there was a stray .svn in folder1 after I rearranged my > workspace. Removing it solved the issue. (SVN client 1.6.6) > > neil.
hint of the day
Just an FYI for anyone that does merging. I just spent an hour cleaning up a mess with my mergeinfo's. I missed a hint that I was about to do something really stupid. Here's the merge: [rele...@zaz1 rel_2_5]$ svn merge $B/rel_2_5_3 --- Merging r14352 through r14594 into '.': Ulcast/build/images/nand/root/lcast/etc/post_install.sh Ulcast/build/images/nand/root/lcast/etc/lc_UpdateNOR.sh G . [rele...@zaz1 rel_2_5]$ svn commit -m 'merge from rel_2_5_3 of a fix made in trunk' Sending. Sendinglcast/build/images/nand/root/lcast/etc/lc_UpdateNOR.sh Sendinglcast/build/images/nand/root/lcast/etc/post_install.sh Transmitting file data .. Committed revision 14595. The hint I missed was the G next to the '.'. That should have told me that there were changes in my workspace, and since I never knowingly commit local changes and merges at the same time, I should have stopped right there. Also, I have some tools that I use to keep track of branches and stuff. Is there a good place to publish them? JLM
RE: hint of the day
The attached archive has 3 files in it BRANCHES is the key file. It lives in the root of trunk. BRANCHES lists all known branches and where they should be merged to. Project branches should have two entries, one "out" to make sure the project branch is staying up to date, and one "in" to make sure that the project merges to somewhere useful someday. There are comments and examples in BRANCHES. changes is a script that checks for all commits since the last time it was run and categorizes them by branch and component (any directory under trunk is a component). It emits a warning if I finds a branch not listed in BRANCHES. tomerge is a script that reminds you of what needs to be merged and from where to where. I run changes and tomerge -c every morning. The path to the repository is hardcoded, as is the location of a workspace. I'd be open to any ideas as to how these could be calculated. JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com <mailto:j...@zeevee.com> www.zeevee.com <http://www.zeevee.com/> From: Erik Andersson [mailto:kir...@gmail.com] Sent: Wednesday, September 01, 2010 8:54 AM To: Jeremy Mordkoff Cc: users@subversion.apache.org Subject: Re: hint of the day On Wed, Sep 1, 2010 at 2:11 PM, Jeremy Mordkoff wrote: Just an FYI for anyone that does merging. I just spent an hour cleaning up a mess with my mergeinfo's. I missed a hint that I was about to do something really stupid. Here's the merge: [rele...@zaz1 rel_2_5]$ svn merge $B/rel_2_5_3 --- Merging r14352 through r14594 into '.': Ulcast/build/images/nand/root/lcast/etc/post_install.sh Ulcast/build/images/nand/root/lcast/etc/lc_UpdateNOR.sh G . [rele...@zaz1 rel_2_5]$ svn commit -m 'merge from rel_2_5_3 of a fix made in trunk' Sending. Sendinglcast/build/images/nand/root/lcast/etc/lc_UpdateNOR.sh Sendinglcast/build/images/nand/root/lcast/etc/post_install.sh Transmitting file data .. Committed revision 14595. The hint I missed was the G next to the '.'. That should have told me that there were changes in my workspace, and since I never knowingly commit local changes and merges at the same time, I should have stopped right there. Also, I have some tools that I use to keep track of branches and stuff. Is there a good place to publish them? I'd like to see them very much. If you don't publish them anywhere, please send them my way. Cheers / Erik JLM svn_tools.tar Description: svn_tools.tar
Renaming a branch
Is there a safe way to rename a branch? I'm worried about all my mergeinfo's
RE: Renaming a branch
> > Is there a safe way to rename a branch? I'm worried about all > > my mergeinfo's > > If you have merged only from trunk and haven't merged from this branch, I don't see a problem > in using s imple svn mv. > I wish it was that simple branches/rel_2_5_3 merges to branches/rel_2_5 which merges to trunk I want to rename rel_2_5 to rel_2_6
RE: Two trunks in one repository?
On Thu, Sep 9, 2010 at 8:38 PM, Tech Geek wrote: So the concepts of trunks, branches, tags are transparent to SVN. We are in a situation where we might need to have two trunks in one SVN repository. The reason is that we have a family of projects - say ProjectA, ProjectB, ProjectC and so on, each one has it's own repository and have just one trunk (normal setup) since the each of these project has just one part. But now let's say we have a ProjectD which has two sub-systems - PartA and PartB whose code is 95% different. So we are thinking to have two trunks inside the ProjectD repository. We would prefer not to create an individual repository for PartA and PartB because we have decided to categorize each of the repository based on the family of Projects - ProjectA, ProjectB, ProjectC, ProjectD. Just wanted to know to get some thoughts from the experts on this mailing list regarding this setup. Any gotachs I need to watch out for? Thanks! === Maybe I missed something in your scenario, but I would simply have one trunk with PartA and PartB as sub-directories. === That would depend mostly on your branch and merge patterns. I have a similar situation. Since every branch has both projects in it, every workspace that I use to do merges has to check out both projects, even though no merge ever contains changes to both projects. Quite a pain in the rear. To make it worse, the unix developers use filenames that cannot be created on a windows system (e.g. AUX, COM1, and COM4), so we can't do merges on windows systems at all. At my top level I have code, vendors and tools. 'code' contains all of our code, the other two are for imports. So instead of /code/trunk/proj1 and /code/trunk/proj2, I should have /code/proj1/trunk and /code/proj2/trunk. Then I could branch and merge each project separately. But before I do this, I should make absolutelty sure that these two projects have no interdependencies. AFAIK, branches are just names. So above and beyond fixing up your mergeinfo's (if you have any), this should work just fine. JLM
RE: Web development development process
> From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] > > We are not a wed design company but we do have a web service team for our Intranet and > Extranet. They have been working, so far with basically a trunk and no branches or tags. So, > we are thinking of reorganising the repository, with the usual trunk/branches/tags. > > Developers will create branches for everything, nothing will be directly developed in trunk, > i.e. trunk will get changed only by reintegrating branches. Is this reasonable? yes > > Tags will be created from trunk but not necessarely always from the HEAD revision. Is this > reasonable? Yes > > They will have one or more staging areas, which will be a WC of a specific tag, for testing. > The Live area will also be a WC of a specific tags. Only the release manager will be able to > switch the staging and Live areas. Is this reasonable? Not sure about staging areas. The live area should belong to operations. > > One of the developers who is working with me (I'm the SVN admin here) on this reorganisation > presented me with a scenario which I'm not sure how to implement. > > Let's supposed that Live is pointing to tag 1.1, and the staging area is pointing to tag 1.2. > Work is going on in branches and trunk does already contain some changes that will released > (tagged) in 1.3. At this point, however, something extremely urgent comes up that need to be > released in Live as soon as possible. How can we do that? > > My idea would be to create a branch from 1.1 tag (the one is in Live), made the change (let's > say committed in revision 1234), and tag it as 1.1.1. Using a stage are to test tag 1.1.1 and > then switch Live to 1.1.1. These changes will need to be done in trunk too, which I think I > can do with a simple merge. This will be agains what I said earlier but it's a special case. A process is only as good as how it works under stress, so don't consider this a special case. This is a quite reasonable approach. > > My next problem however is the current 1.2 tag. It does not have the changes in revision > 1234, so basically the test I'm doing on the staging area is useless, as I could never > release it. I would need to somehow, create a new 1.2.1 tags, as a copy of 1.2 plus the > changes in revision 1234. Yes. I would have a rel 1.1 branch and a rel 1.2 branch. I would merge from rel 1.1 to rel 1.2 to trunk. I would tag each branch whenever I did a release. > > Is all this a correct way to proceed? I'm sure other people have come across a problem > similar to this, and I would really appreciate any input on how to implement such process. Basically, yes. Now, can anyone point me to a bug tracking system that could capture this? E.g. is there a system That could tell me "found in 1.0, fixed in 1.1, 2.1 and 3.0"?
RE: subversion configuration problem
Have you checked your firewall settings on the Windoze server? Can you telnet to the SVN port from the client? jlm Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com <mailto:j...@zeevee.com> www.zeevee.com <http://www.zeevee.com/> From: Kayhan Yüksel [mailto:kayh...@fasdat.com.tr] Sent: Wednesday, September 15, 2010 8:09 AM To: users@subversion.apache.org Cc: İsmail Hakkı ŞAHİN Subject: subversion configuration problem To whom it may respond to, We have been required to setup a svn server without using Apache Server on a Windows 2008 Server. After installing SlikSVN , we have created a test repository using svnadmin at c:\svn\repos and started SVNSERVE as deamon. As a client, we are testing AnkhSVN inside VS 2010 , but couldn't connect using svn://machinename/svn/repos , after opening the svn folder to sharing, we have been able to reach via file://machinename/svn/repos , but this is not a good method to live with. How can we setup slikSVN + AnkhSVN to use svn protocol for communications ? Thank you for your concern, Best Regards, Kayhan YÜKSEL FASDAT GIDA A.Ş. IT Department Software Developer __ Information from ESET NOD32 Antivirus, version of virus signature database 5452 (20100915) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
RE: subversion configuration problem
Can you ping it by name? by address? Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com <mailto:j...@zeevee.com> www.zeevee.com <http://www.zeevee.com/>
RE: subversion configuration problem
On the windows servers, open a command prompt and run 'netstat -n -a' You should see a line something like TCP 0.0.0.0:3690 0.0.0.0:0 listening If it is not there, the server is not running or it is running on the wrong port. If it is there, you have a routing or firewall issue You can also try 'telnet 127.0.0.1 3690' right on the server JLM
RE: Web development development process
What's wrong with using working copies for production? We did configure apache to reject any request with .svn in the url. It means that my deployment vehicle is a simple 'svn co' or 'svn switch'. No messing around with packaging up the files, etc. And this really comes in handy when an update goes bad and I need to revert quick. Plus all I have to do to release to QA is give them the branch and revision. I can check that nobody has messed with anything on the production server with a simple 'svn status'. And I can revert any such change (or commit it if I made it :) ) I even have /etc under svn now :) Makes it very easy to deploy new servers. I request a new hardware unit and the hosting company installs the OS. I install some ssh keys and install/update a handful of packages, do a couple svn co's and update public DNS and I'm up and running. JLM Jeremy L. Mordkoff
RE: Choosing a server
Are you hosting the server only, or will you also be hosting working copies? Spread working copies across spindles and put the server on its own spindle to reduce latency. JLM
RE: To branch or not to branch unique projects started from a common code set
You need to think about your build process and software architecture and then design your branching strategy to support it. For instance, if you find a bug in the base code, how are you going to get that fix out to all of your customers? One solution is to develop your base code as one project, and then for each customer, treat the base code as a vendor branch, where you accept updates from the base project and merge them into each customers area. The biggest downside is that it will be real easy to make a fix in a customer area that really should have been in the common area. This assumes that there is significant overlap between your base code and the custom code. If the architecture is such that the custom code layers on top of the base code but never changes it, then there are probably two projects. A 'release' would then be a base build plus a custom build. Then the big question is there common customer code. Is there a base class from which all customer code is derived? You need to think about your build process and software architecture and then design your branching strategy to support it. JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
RE: Choosing a server
I control the subversion server and the servers that host the working copies. If the working copies are elsewhere, my point is irrelevant. JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com > -Original Message- > From: Gary [mailto:subversion-u...@garydjones.name] > Sent: Friday, September 17, 2010 2:19 AM > To: users@subversion.apache.org > Subject: Re: Choosing a server > > Jeremy Mordkoff wrote: > > Are you hosting the server only, or will you also be hosting working > > copies? Spread working copies across spindles and put the server on its > > own spindle to reduce latency. > > Maybe I don't understand you, but (obviously, I thought) the working > copies will be local to the small number of users who will be using > subversion.
[BUG] $URL keyword is not updated on 'svn switch'
I did an 'svn switch' to change between trunk and a release branch of clang, and the built binary still reported it was built on trunk. It uses $URL to determine this: I did an 'svn switch' from clang trunk to the 2.8 branch, and the $URL property was not updated on Version.cpp: ~/src/llvm/tools/clang/lib/Basic $ grep '\$URL' Version.cpp static const char URL[] = "$URL: http://llvm.org/svn/llvm-project/cfe/trunk/lib/Basic/Version.cpp $"; ~/src/llvm/tools/clang/lib/Basic $ svn info Version.cpp Path: Version.cpp Name: Version.cpp URL: http://llvm.org/svn/llvm-project/cfe/branches/release_28/lib/Basic/Version.cpp Repository Root: http://llvm.org/svn/llvm-project Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8 Revision: 114256 Node Kind: file Schedule: normal Last Changed Author: ddunbar Last Changed Rev: 103192 Last Changed Date: 2010-05-06 11:39:38 -0700 (Thu, 06 May 2010) Text Last Updated: 2010-05-30 17:21:25 -0700 (Sun, 30 May 2010) Checksum: 2bae87644b9b641237ed3724456d938b ~/src/llvm/tools/clang/lib/Basic $ svn pl Version.cpp Properties on 'Version.cpp': svn:keywords ~/src/llvm/tools/clang/lib/Basic $ svn pg svn:keywords Version.cpp URL ~/src/llvm/tools/clang/lib/Basic $ rm Version.cpp ~/src/llvm/tools/clang/lib/Basic $ svn update Restored 'Version.cpp' At revision 114268. ~/src/llvm/tools/clang/lib/Basic $ grep '\$URL' Version.cpp static const char URL[] = "$URL: http://llvm.org/svn/llvm-project/cfe/branches/release_28/lib/Basic/Version.cpp $";
RE: svn merge --reintegration.
A merge to a new branch based on the head of trunk should be no different than a merge to trunk itself. The secondary merge of the newly merged branch to trunk will be trivial. I still often do exactly what you propose so that I can test and debug the merged code before committing it to trunk. So the real question is, merge from trunk to branch first or just merge from branch to trunk and be done with it? I usually decide based on two things. Is the branch obsolete after this operation? If so, I merge from branch to trunk. If not, I ask myself which changes am I more familiar with and I merge FROM there. For some reason I find this easier. If the merge is painful due to conflicts, I sometimes do the merge one changeset at a time. Have you figured out whether or not the conflicts are due to white space issues such as new lines/carriage returns, tabs/spaces or other reformatting issues? jlm
post-commit notify scripts
I use a post commit script to send email to a list whenever anyone commits anything. I want to start filtering that now. Anyone done this and willing to share any tools? JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com <mailto:j...@zeevee.com> www.zeevee.com <http://www.zeevee.com/>
undo a switch
Please tell me there's a way to undo a 'svn switch' I tracked down an old working copy for an engineer that had moved on long ago because he had done some work that had never gotten checked in. The view was hopelessly out of date so I did svn copy -r svn://svn/zcode/trunk svn://svn/zcode/branches/jlm_temp1 svn switch svn://svn/zcode/branches/jlm_temp1 where xxx was (I thought) the revision of his view. I thought this would give me a quick way to check in his work just as I found it. But when I did the switch, I got conflicts, so I'm guessing I got the revision wrong. SO...is there a way to get back? JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
reintegrate fails due to "claimed" incomplete merge-out
(Not ont mailing list so please cc me) I really have tried many many things to resolve this problem — endless searching, commits, un-commits etc. But I’m stuck. I think I see the issue(subdir merge of “…bitstream"), but have tried to do —record-only merges, merges, propedits… all to no avail. The information below is after an un-commit of all changes back to just after the last merge-out from trunk to the branch (yellowstone). Although, it’s hard to deal with the concept that after doing a merge out to the branch that —reintegrate should fail That just seems wrong. Any help on this would be immensely grateful — before this marathon of svn-ing, I didn’t even know what mergeinfo was :) And I clearly still don’t get something. On trunk: jgreene@spi3:/home/jgreene/views/latest3$ svn merge --reintegrate ^/z4/branches/yellowstone svn: Reintegrate can only be used if revisions 27743 through 28342 were previously merged from svn://svn/z4/trunk to the reintegrate source, but this is not the case: z4/branches/yellowstone Missing ranges: /z4/trunk:27879-28339 jgreene@spi3:/home/jgreene/views/latest3$ Below is the output from "svn pg svn:mergeingo -R ." at the root of the branch "yellowstone" workspace. All of the merge info records go from 27743 (branch start) to 28341 EXCEPT: z4/trunk/third_party/bitstream/mpeg:27938-28341 z4/trunk/third_party/bitstream/atsc:27938-28341 z4/trunk/third_party/bitstream:27879-28040*,28041-28341 z4/trunk/third_party/bitstream/dvb:27938-28341 z4/trunk/third_party/bitstream/common.h:27938-28341 z4/trunk/third_party/bitstream/ietf:27938-28341 FULL mergeinfo output on yellowstone branch (relating to merges out from trunk): rapidev2_release - z4/trunk/rapidev2_release:24018,27743-28341 fw - z4/trunk/fw:24018,27743-28341 third_party/freetype - z4/trunk/third_party/freetype:24018,27743-28341 Makefile - z4/trunk/Makefile:24018,27743-28341 third_party/freeimage - z4/trunk/third_party/freeimage:24018,27743-28341 third_party/openssl/md5.h - z4/trunk/third_party/openssl/md5.h:24018,27743-28341 third_party/zlib - z4/trunk/third_party/zlib:24018,27743-28341 README - z4/trunk/README:24018,27743-28341 third_party/curl - z4/trunk/third_party/curl:24018,27743-28341 third_party/openssl/notes - z4/trunk/third_party/openssl/notes:24018,27743-28341 bsp/u-boot_sp2x - z4/trunk/bsp/u-boot_sp2x:24018,27743-28341 third_party/Makefile - z4/trunk/third_party/Makefile:24018,27743-28341 third_party/openssl/e_os2.h - z4/trunk/third_party/openssl/e_os2.h:24018,27743-28341 third_party/Makefile.curl - z4/trunk/third_party/Makefile.curl:24018,27743-28341 third_party/bitstream/mpeg - z4/trunk/third_party/bitstream/mpeg:27938-28341 -- third_party/openssl - z4/trunk/third_party/openssl:24018,27743-27878,27879-28341* third_party/bitstream/atsc - z4/trunk/third_party/bitstream/atsc:27938-28341 -- fpga - z4/trunk/fpga:24018,27743-28341 . - z4/trunk:24018,27743-27878,27879-28341* bsp/kernel_sp2x - z4/trunk/bsp/kernel_sp2x:24018,27743-28341 third_party/openssl/libcrypto_linux.a - z4/trunk/third_party/openssl/libcrypto_linux.a:24018,27743-28341 third_party/bitstream - z4/trunk/third_party/bitstream:27879-28040*,28041-28341 -- third_party/openssl/libcrypto_win32.a - z4/trunk/third_party/openssl/libcrypto_win32.a:24018,27743-28341 bsp - z4/trunk/bsp:24018,27743-27878,27879-28341* third_party/sha1 - z4/trunk/third_party/sha1:24018,27743-28341 third_party - z4/trunk/third_party:24018,27743-27878,27879-28341* third_party/openssl/opensslconf.h - z4/trunk/third_party/openssl/opensslconf.h:24018,27743-28341 rapidev2_dyn_src - z4/trunk/rapidev2_dyn_src:24018,27743-28341 third_party/bitstream/dvb - z4/trunk/third_party/bitstream/dvb:27938-28341 -- build - z4/trunk/build:24018,27743-28341 rapidev2_pkgs - z4/trunk/rapidev2_pkgs:24018,27743-28341 third_party/bitstream/common.h - z4/trunk/third_party/bitstream/common.h:27938-28341 -- third_party/libupnp - z4/trunk/third_party/libupnp:24018,27743-28341 third_party/libpng - z4/trunk/third_party/libpng:24018,27743-28341 Makefile.HELP - z4/trunk/Makefile.HELP:24018,27743-28341 third_party/openssl/libcrypto_s1.a - z4/trunk/third_party/openssl/libcrypto_s1.a:24018,27743-28341 third_party/openssl/libcrypto_s2.a - z4/trunk/third_party/openssl/libcrypto_s2.a:24018,27743-28341 third_party/dhcp - z4/trunk/third_party/dhcp:24018,27743-28341 third_party/bitstream/ietf - z4/trunk/third_party/bitstream/ietf:27938-28341 -- third_party/mtd-utils - z4/trunk/third_party/mtd-utils:24018,27743-28341
