Re: Doing svn checkouts on top of svn checkouts?????
> > Geoff Hoffman wrote on Mon, Jul 11, 2011 at 18:20:41 -0700: > > This is a feature, yes. Subversion does allow your working copy to point > to > > more than 1 svn path. > > > On Mon, Jul 11, 2011 at 7:21 PM, Daniel Shahaf wrote: > Geoff: you cannot point a single working copy item at more than one URL. > (well, unless you create two externals with the same target file. Don't > do that.) > You're right, Daniel. *item* yes. To clarify what I meant - say you have Repo-A/Path-B and Repo-X/Path-Y. You could cd into your working copy of Path-B and do svn checkout Repo-X/Path-Y Y and end up with B/Y in your working copy such that changes under Y commit to Repo-X and changes under B not under Y commit to Repo-A. I have a hunch this (not throwing an error) is by design, because it is *almost* identical to how svn:externals work. I just tested this and Y shows up as ? when doing svn status under B.
Re: Doing svn checkouts on top of svn checkouts?????
On Tue, 12 Jul 2011 00:30:06 +, Geoff Hoffman wrote: ... > To clarify what I meant - say you have Repo-A/Path-B and Repo-X/Path-Y. You > could cd into your working copy of Path-B and do svn checkout Repo-X/Path-Y > Y and end up with B/Y in your working copy such that changes under Y commit > to Repo-X and changes under B not under Y commit to Repo-A. I have a hunch > this (not throwing an error) is by design, because it is *almost* identical > to how svn:externals work. I just tested this and Y shows up as ? when > doing svn status under B. I didn't test that, but I suppose that Y is not known to the 'outer' svn sandbox, and changes in the 'inner sandbox (Y) wouldn't be committed or shown in 'svn status'. Can you 'svn switch' a subtree to a different repo? And what happens then on a commit? :-) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Cannot create repository
The installation was successfull, but i cannot create a repository. Here is the output: --- [root@mycomputer me]# svnadmin create /var/svn/repos Check that the folder /var/svn is already created. I think, that folder is not there. Regards, Shrinivasan CollabNet Support
RE: Doing svn checkouts on top of svn checkouts?????
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: dinsdag 12 juli 2011 5:47 > To: Nico Kadel-Garcia > Cc: Geoff Hoffman; Subversion > Subject: Re: Doing svn checkouts on top of svn checkouts? > > Nico Kadel-Garcia wrote on Mon, Jul 11, 2011 at 23:42:07 -0400: > > On Mon, Jul 11, 2011 at 10:21 PM, Daniel Shahaf > wrote: > > > Geoff: you cannot point a single working copy item at more than one > URL. > > > (well, unless you create two externals with the same target file. Don't > > > do that.) > > > > > > Nico: explain /exactly/ what you have been doing (best: a script(1) > > > transcript). I don't know if you are complaining about nested working > > > copies, or about running svn co $URL $dir where $dir is a subdir or root > > > of a working copy, or something else altogether. > > > > Oh, it's not *me* doing it. Someone, as part of their software build > > environment, is doing the moral equivalent in their setup scripts of > > this: > > > >svn checkout $URL $targetdir > >make -C $targetdir install > > > > Then, for testing, they do this > > > >cd $targetdir > > # Edit local files, not necessarily submitted to > > upstream repository > > > > Then a day or a week later, they re-run the script. > > > > svn checkout $URL $targetdir > > AFAIK, this will run 'svn up' and not lose local mods. This will just verify if $URL matches the URL of $targetdir and if it doesn't you will get an error. If the test passes it will just perform an update to the requested revision (or in this case HEAD) This was originally designed so you could create restartable scripts that perform a checkout. So if the checkout fails you can just rerun checkout and it continues where it stopped the last time. (For scripts this might be easier than running 'svn update $targetdir) Bert
RE: Doing svn checkouts on top of svn checkouts?????
> -Original Message- > From: Andreas Krey [mailto:a.k...@gmx.de] > Sent: dinsdag 12 juli 2011 10:07 > To: Geoff Hoffman > Cc: Subversion > Subject: Re: Doing svn checkouts on top of svn checkouts? > > On Tue, 12 Jul 2011 00:30:06 +, Geoff Hoffman wrote: > ... > > To clarify what I meant - say you have Repo-A/Path-B and Repo-X/Path-Y. > You > > could cd into your working copy of Path-B and do svn checkout Repo- > X/Path-Y > > Y and end up with B/Y in your working copy such that changes under Y > commit > > to Repo-X and changes under B not under Y commit to Repo-A. I have a > hunch > > this (not throwing an error) is by design, because it is *almost* identical > > to how svn:externals work. I just tested this and Y shows up as ? when > > doing svn status under B. > > I didn't test that, but I suppose that Y is not known to the 'outer' > svn sandbox, and changes in the 'inner sandbox (Y) wouldn't be committed > or shown in 'svn status'. > > Can you 'svn switch' a subtree to a different repo? And what happens > then on a commit? :-) No, you can't switch a subtree to a different repository. You can exclude a directory and perform a new checkout in its place though. But this starts a new working copy. Bert
RE: Perplexing results of SVN commit
> -Original Message- > From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] > Sent: dinsdag 12 juli 2011 4:13 > To: Warren Jones > Cc: users@subversion.apache.org > Subject: Re: Perplexing results of SVN commit > > On Jul 11, 2011, at 14:07, Warren Jones wrote: > > > One of our developers got perplexing results from an SVN commit. As far > as I can tell, this is what happened: > > > >1. Developer checks out trunk of SVN project to working directory. > >2. "svn copy" some files from branch into working directory. > >3. Edit and modify files copied from branch. > >4. "svn commit" in working directory. > > > > After the commit: > > > >1. "svn status" shows the working directory is up to date. > >2. "svn diff" shows no modified files in the working directory. > >3. Repository contains files copied from branch to trunk. > >4. Repository **does not** contain subsequent mods to those files. The > commit somehow missed these changes. > >5. File mods are still in the working directory, although not shown by "svn > diff". > >6. After file time stamps are updated with "touch", "svn diff" shows > changes. > > > > I'm unable to reproduce this odd state of affairs, but I have the repository > and the developer's working directory to prove that something went wrong > with the commit. I don't know whether it was operator error or a bug in SVN. > > Sounds to me like operator error of the following kind: the developer > modified the files in the working copy, and also made identical modifications > to the corresponding pristine files in .svn/text-base (frequently this happens > when using a batch search-replace tool). Because even after the edits the > contents of the pristine files match the regular files, "svn st" and "svn di" > don't show the changes and they don't get committed. > > If this is what happened, check out a fresh working copy, manually copy over > the changed files, and commit them. And ensure that in the future you do > not edit anything in the .svn directories. Some batch search-replace tools let > you define directories they're not to touch. 'svn status' only notices that files are modified if either the size or the date changed since the last subversion operation that modified the file. (Subversion automatically waits for some time to make sure other tools can't change files in the same second when the filesystem has less than or exactly 1 second timestamp precision) A clock skew between tool and filesystem might introduce this problem if you have a script that updates files directly after update. But personally I would guess that Ryan's answer is far more likely as usually at least some file sizes change. Bert
AW: Perplexing results of SVN commit
Hi, Ryan, Von: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] > > Sounds to me like operator error of the following kind: the developer > modified the files in the working copy, and also made identical > modifications to the corresponding pristine files in .svn/text-base > (frequently this happens when using a batch search-replace tool). Because > even after the edits the contents of the pristine files match the regular > files, "svn st" and "svn di" don't show the changes and they don't get > committed. > > If this is what happened, check out a fresh working copy, manually copy > over the changed files, and commit them. And ensure that in the future you > do not edit anything in the .svn directories. Some batch search-replace > tools let you define directories they're not to touch. This kind of problem seems to be rather common. What about an additional option to "svn cleanup" to check the validity of the base files, and restore them from the repository? Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: AW: Perplexing results of SVN commit
On 7/12/11 7:18 AM, Markus Schaber wrote: Sounds to me like operator error of the following kind: the developer modified the files in the working copy, and also made identical modifications to the corresponding pristine files in .svn/text-base (frequently this happens when using a batch search-replace tool). [...] This kind of problem seems to be rather common. What about an additional option to "svn cleanup" to check the validity of the base files, and restore them from the repository? Or even better, an optional cvs-like mode where you don't need the pristine copies on the client at all. -- Les Mikesell lesmikes...@gmail.com
Web page problem
This is not a bug. You used to post the current fully qualified version of Subversion on your home page. Today you stopped doing that. This makes automated version release detection difficult. Please go back to posting it. -- click attached vCard (Rolodex icon) for contact details <>
Re: Web page problem
On Mon, Jul 11, 2011 at 04:16:07PM -0700, Roedy Green wrote: > This is not a bug. You used to post the current fully qualified version > of Subversion on your home page. Today you stopped doing that. I am not entire sure what you mean. But the news section has accumulated enough entries to move mention of the lastest stable release off the main page. Maybe this is what you mean? > This makes automated version release detection difficult. Please go back to > posting it. See the big yellow box at http://subversion.apache.org/download/ Maybe that helps?
Re: Perplexing results of SVN commit
On Mon, 11 Jul 2011 21:13:22 +, Ryan Schmidt wrote: ... > Sounds to me like operator error of the following kind: the developer > modified the files in the working copy, and also made identical modifications > to the corresponding pristine files in .svn/text-base (frequently this > happens when using a batch search-replace tool). This would lead me to hope that svn 1.7 will not store the pristine copies unobfuscated (like, compressed or in a database) so they are not that easily found. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Perplexing results of SVN commit
On Tue, Jul 12, 2011 at 03:15:33PM +0200, Andreas Krey wrote: > On Mon, 11 Jul 2011 21:13:22 +, Ryan Schmidt wrote: > ... > > Sounds to me like operator error of the following kind: the developer > > modified the files in the working copy, and also made identical > > modifications to the corresponding pristine files in .svn/text-base > > (frequently this happens when using a batch search-replace tool). > > This would lead me to hope that svn 1.7 will not store the pristine > copies unobfuscated (like, compressed or in a database) so they are not > that easily found. Nope, 1.7 won't obfuscate pristines in any way. But you can filter them out via the filename pattern '*.svn-base' (as you already can do with 1.6).
Re: Web page problem
Or, you know, a cron job that runs 'svn ls ^/subversion/tags'. Stefan Sperling wrote on Tue, Jul 12, 2011 at 15:15:09 +0200: > On Mon, Jul 11, 2011 at 04:16:07PM -0700, Roedy Green wrote: > > This is not a bug. You used to post the current fully qualified version > > of Subversion on your home page. Today you stopped doing that. > > I am not entire sure what you mean. > > But the news section has accumulated enough entries to move mention > of the lastest stable release off the main page. Maybe this is what > you mean? > > > This makes automated version release detection difficult. Please go back to > > posting it. > > See the big yellow box at http://subversion.apache.org/download/ > Maybe that helps?
Re: Perplexing results of SVN commit
On Jul 12, 2011, at 07:43, Les Mikesell wrote: > Or even better, an optional cvs-like mode where you don't need the pristine > copies on the client at all. The request to allow working copies without text-base is filed here: http://subversion.tigris.org/issues/show_bug.cgi?id=525 Related is the request to allow the text-base to be compressed: http://subversion.tigris.org/issues/show_bug.cgi?id=908
AW: AW: Perplexing results of SVN commit
Hi, Von: Les Mikesell [mailto:lesmikes...@gmail.com] > >> > >> Sounds to me like operator error of the following kind: the developer > >> modified the files in the working copy, and also made identical > >> modifications to the corresponding pristine files in .svn/text-base > >> (frequently this happens when using a batch search-replace tool). > > > [...] > > This kind of problem seems to be rather common. What about an > > additional option to "svn cleanup" to check the validity of the base > > files, and restore them from the repository? > > Or even better, an optional cvs-like mode where you don't need the > pristine copies on the client at all. I would not call this "better" - I prefer to work offline, and use a connection to the server only when needed. Best regards Markus Schaber
Re: Perplexing results of SVN commit
On Mon, Jul 11, 2011 at 07:13:22PM -0700, Ryan Schmidt wrote: > Sounds to me like operator error of the following kind: the developer > modified the files in the working copy, and also made identical modifications > to the corresponding pristine files in .svn/text-base (frequently this > happens when using a batch search-replace tool). Thanks, that seems like a reasonable suggestion. However, files in .svn/text-base are unmodified. "svn diff" doesn't show modified files in the working directory because timestamps and file sizes match values in .svn/entries. The md5sum in .svn/entries doesn't match the working file, but apparently that isn't checked as long as timestamp and file size are consistent. For what it's worth, here are some time stamps: 2011-03-10 10:09:15.36 .svn/text-base/file 2011-03-10 11:02:49.375390 repository (commit) 2011-03-10 11:02:51.211718 working file 2011-03-10 11:02:51.227692 .svn/entries I'm guessing the working file was touched ~2 seconds after the commit to update embedded keywords. -- Warren Jones Fluke Corporation Software Engineering Support Group
