Re: problem with dialog box uisng Tortoisesvn
thanks for your help.
Seems like I didn't have the whole svn package.
I reinstalled the svn and made sure I pick the "command tool" and now the
svn commands work for me.
Though I have a problem with the tag command:
I wrote a script in perl:
my $target_path = "file:///C:/svn_repos3/trunk/Widget3"
my $tag = "file:///C:/svn_repos3/tags/Release_63"
system ("svn copy -m \"tagging the file\" \"$target_path\" \"$tag\" ");
and got the following error:
svn: E160005: Invalid control character '0X0a' in path 'Release_63\012'
Does anyone know what this error is?
thanks!!
On Wed, Sep 5, 2012 at 1:21 PM, Ryan Schmidt <
subversion-20...@ryandesign.com> wrote:
>
> On Sep 5, 2012, at 04:14, Carmit Shiran wrote:
>
> > c:\Program files\TortoiseSVN\bin> $svn commit
> >
> > I got the following message:
> > '$svn' is not recognized as an internal or external command, operable
> program or batch file.
>
> You're not supposed to type "$". We just use "$" to indicate "type the
> things after this". It's a fairly common character for a command prompt.
> This same convention is used by the SVN Book [1], which is a good document
> to read to get familiar with how to use Subversion.
>
>
> [1] http://svnbook.org/
>
>
>
>
>
>
Re: Git smudge / Clean / Filter alike in Subversion ?
Le 11/09/2012 17:58, Stefan Sperling a écrit : On Tue, Sep 11, 2012 at 04:48:12PM +0200, Laurent Alebarde wrote: Le 11/09/2012 15:49, Stefan Sperling a écrit : On Tue, Sep 11, 2012 at 02:45:49PM +0200, Laurent Alebarde wrote: Thanks for your answer Stefan, Unfortunatly, no : The first link says Subversion is smart with binary files. That's good to hear, but do not provide a filter or filter hook between the workspace and the repository. Apart from built-in properties such as svn:keywords and svn:eol-style, there is no way to make changes to files during checkout or commit. You can probably use a wrapper script for this purpose, however, that wraps svn checkout, svn update, and svn commit. What do you really need this feature for? I'm interested in learning more about your actual use case, the actual problem you're trying to solve, rather than what git's solution to your problem is. Maybe if I knew more about the problem itself I could give you a better answer. And maybe we can add some feature to svn to solve your problem, once we understand the problem. Sure, you are right. At present time, my use cases are : 1) Automatic coding style refactoring so that developpers remain happy with what they are used to : indentation, naming, layout, etc. In Subversion you can block commits that do not conform to policy by creating a pre-commit hook that evaluates changes about to be committed, and allows or rejects the commit based on that. This then requires developers to e.g. heed coding style to be able to commit. They could also use tools to modify files in their working copy before committing. I.e. the only difference is that there is no way to plug the "fix-up tooling" into svn itself, but that people are required to use this tooling in _addition_ to svn, before committing. So the best way for me woudl be to use a "dummy" workspace copy before commiting, and another one after check-outing : WS ---pre-commit-treatment-(git-clean)---> dummy WS ---commit---> Repository Repository ---check-out---> another dummy WS ---post-check-out-treatment-(git-smudge)---> WS However, if your pre-commit checks are too strict and there is no way to bypass them, people might end up not committing at all for longer than necessary, which is also bad. You should at least provide a way to bypass these checks (e.g. by putting a special marker into the log message) to allow for unforeseen circumstances where developers need to override these checks. One idea behind all that is I don't want to block at all. 2) Automatic doxygen comments generation. If this can be done in an automated way, why bother developer working copies with it at all? You could create an automated job that has its own working copy, updates to get new changes, makes any necessary doxygen modifications, and commits the result. svn can be scripted for these kinds of purposes. See the --non-interactive and --xml options that many svn commands support. Please, cf my other answer in a separate message. 3) Add information in the code in the workspace, from tags included in the repository The 2 first use cases need a filter between the workspace and the repository. The 3rd one needs a filter between the workspace and the internal or external diff. I don't think I understand 3), especially what diff has got to do with it. What is this for? As code in each developper WS is not standard, I cannot diff code from a WS and the repository directly. Files have to be in the same referential. So either I "smudge" the file coming from the repository before diff-ing it with the file of the WS, either I "clean" the WS file, before diff-ing it with the repository file. Is this information meant for interactive use by developers while developing? Or is it some extended information of the sort that svn:keywords supports, which is embedded in files you ship to customers (outside the version control system)? Yes, for my 3rd use case, svn:keywords does the trick. Thanks. But svn:keywords are not enough though to solve my diff paradigm above. In the latter case, you might as well use a separate working copy to add this extra information, and commit it from there, instead of forcing unrelated changes into developer working copies. I realise that git can easily hide modifications by automatically making them in the index instead of the working tree. So if you're adding information which developers don't really need to see on they fly while files are being added to the index, this doesn't bother them much. However, Subversion does not have a concept of an "index" like git does. There is only a working copy and a repository. So you're really talking about making edits to peoples' working files, which may or may not be desirable, depending on the use case. And keep in mind that developers might have their files opened up in editors while they run 'svn update' or 'svn commit', and you would be making changes to the files concurrently. I'd imagine that could l
Re: Git smudge / Clean / Filter alike in Subversion ?
Le 11/09/2012 17:47, Ryan Schmidt a écrit : On Sep 11, 2012, at 09:48, Laurent Alebarde wrote: Le 11/09/2012 15:49, Stefan Sperling a écrit : What do you really need this feature for? I'm interested in learning more about your actual use case, the actual problem you're trying to solve, rather than what git's solution to your problem is. Maybe if I knew more about the problem itself I could give you a better answer. And maybe we can add some feature to svn to solve your problem, once we understand the problem. Sure, you are right. At present time, my use cases are : 1) Automatic coding style refactoring so that developpers remain happy with what they are used to : indentation, naming, layout, etc. The usual Subversion solution for this is to either a) write a pre-commit hook that verifies that the code conforms to the style guidelines, and rejects the commit if it does not; or Our policies are : "developpers feel like at home" and "tools shall adapt to developpers". I recognise it is unusual and dissonant. So developpers use their coding style they are efficient with and I translate that to something standard. I induce the rules to provide the developper with something he could have written himself when check-out. I could find examples of pre-commit hooks, for example to convert indentation from spaces to tabs or the opposite. Then I could find the lists of available hooks in the documentation. If I am not mistaken, there is no hook available in the opposite direction, say in the check-out process ? b) write a post-commit hook that converts code to the required style and commits this in a second revision 2) Automatic doxygen comments generation. Here too the usual Subversion solution is to have a post-commit hook generate this and then commit it. Another common answer is that things that can be generated should not be stored in the repository. I agree with you, except in the case of a heavy process, though another shared storega place can be found instead of the svn repository. But keeping it in svn anable to apply patches of manual updates from versions to versions. I mean the documentation is only around 75% automatized. 3) Add information in the code in the workspace, from tags included in the repository I don't understand... could you give an example? Please, cf my other answer in a separate message.
RE: problem with dialog box uisng Tortoisesvn
From: Carmit Shiran [mailto:carmit.shi...@gmail.com]
Sent: 12 September 2012 08:14
To: Ryan Schmidt
Cc: Cooke, Mark; users@subversion.apache.org
Subject: Re: problem with dialog box uisng Tortoisesvn
thanks for your help.
Seems like I didn't have the whole svn package.
I reinstalled the svn and made sure I pick the "command tool" and now the svn
commands work for me.
Though I have a problem with the tag command:
I wrote a script in perl:
my $target_path = "file:///C:/svn_repos3/trunk/Widget3"
my $tag = "file:///C:/svn_repos3/tags/Release_63"
system ("svn copy -m \"tagging the file\" \"$target_path\" \"$tag\" ");
and got the following error:
svn: E160005: Invalid control character '0X0a' in path 'Release_63\012'
Does anyone know what this error is?
That's just a line feed at the end of one of your variable strings. Use chomp
to get rid of it and you should be golden.
Tony.
thanks!!
On Wed, Sep 5, 2012 at 1:21 PM, Ryan Schmidt
mailto:subversion-20...@ryandesign.com>> wrote:
On Sep 5, 2012, at 04:14, Carmit Shiran wrote:
> c:\Program files\TortoiseSVN\bin> $svn commit
>
> I got the following message:
> '$svn' is not recognized as an internal or external command, operable program
> or batch file.
You're not supposed to type "$". We just use "$" to indicate "type the things
after this". It's a fairly common character for a command prompt. This same
convention is used by the SVN Book [1], which is a good document to read to get
familiar with how to use Subversion.
[1] http://svnbook.org/
__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2221 / Virus Database: 2437/5262 - Release Date: 09/11/12
__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
Re: problem with dialog box uisng Tortoisesvn
Thanks! It works for me now!
another short question:
Do you know if there's a way to know what is the current tag I'm working
on? Meaning: If I want to use 'svn copy' on the file I'm working on now
without sending the argument of the source file but only the tag name, is
it possible to send the 'current file path' as the first argument?
For instance, if the user doesn't know on what tag he's working on,
assuming he's not working on the 'trunk' but rather on 'tag= Release_60'.
And now he wants to copy 'Release_60' to 'Release_61'. But he doesn't know
he's working on 'Release_60'. How do I find out using svn command lines?
If you look at my example I sent in the previous email, you can see I
filled in the argument= $target_path :
my $target_path = "file:///C:/svn_repos3/trunk/Widget3"
But I'm looking for a way to fill it automatically with the "current
path/tag".
Is it possible?
Thanks a lot!
have a great day!
On Wed, Sep 12, 2012 at 12:10 PM, Tony Sweeney wrote:
> **
>
>
> --
> *From:* Carmit Shiran [mailto:carmit.shi...@gmail.com]
> *Sent:* 12 September 2012 08:14
> *To:* Ryan Schmidt
> *Cc:* Cooke, Mark; users@subversion.apache.org
> *Subject:* Re: problem with dialog box uisng Tortoisesvn
>
> thanks for your help.
> Seems like I didn't have the whole svn package.
> I reinstalled the svn and made sure I pick the "command tool" and now the
> svn commands work for me.
>
> Though I have a problem with the tag command:
>
> I wrote a script in perl:
> my $target_path = "file:///C:/svn_repos3/trunk/Widget3"
> my $tag = "file:///C:/svn_repos3/tags/Release_63"
>
> system ("svn copy -m \"tagging the file\" \"$target_path\" \"$tag\" ");
>
> and got the following error:
>
> svn: E160005: Invalid control character '0X0a' in path 'Release_63\012'
>
> Does anyone know what this error is?
>
> That's just a line feed at the end of one of your variable strings. Use
> chomp to get rid of it and you should be golden.
>
> Tony.
>
> thanks!!
>
>
>
> On Wed, Sep 5, 2012 at 1:21 PM, Ryan Schmidt <
> subversion-20...@ryandesign.com> wrote:
>
>>
>> On Sep 5, 2012, at 04:14, Carmit Shiran wrote:
>>
>> > c:\Program files\TortoiseSVN\bin> $svn commit
>> >
>> > I got the following message:
>> > '$svn' is not recognized as an internal or external command, operable
>> program or batch file.
>>
>> You're not supposed to type "$". We just use "$" to indicate "type the
>> things after this". It's a fairly common character for a command prompt.
>> This same convention is used by the SVN Book [1], which is a good document
>> to read to get familiar with how to use Subversion.
>>
>>
>> [1] http://svnbook.org/
>>
>>
>>
>>
>>
>>
>
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
> --
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2221 / Virus Database: 2437/5262 - Release Date: 09/11/12
>
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
>
Re: Git smudge / Clean / Filter alike in Subversion ?
On Wed, Sep 12, 2012 at 11:41:05AM +0200, Laurent Alebarde wrote: > I could find examples of pre-commit hooks, for example to convert > indentation from spaces to tabs or the opposite. This is very wrong. Pre-commit hooks are not supposed to modify the content of commit transactions. Doing so causes the working copy and the repository to get out of sync, having conflicting ideas about what was committed. Don't do this! > Then I could find > the lists of available hooks in the documentation. If I am not > mistaken, there is no hook available in the opposite direction, say > in the check-out process ? No, there are no hooks during checkout. TortoiseSVN has client-side hooks, however. You might be able to leverage those. But I don't know details of how they work. And this would force all developers to use TortoiseSVN.
Re: Git smudge / Clean / Filter alike in Subversion ?
On Wed, Sep 12, 2012 at 11:40:58AM +0200, Laurent Alebarde wrote: > So the best way for me woudl be to use a "dummy" workspace copy > before commiting, and another one after check-outing : > > WS ---pre-commit-treatment-(git-clean)---> dummy WS ---commit---> Repository > > Repository ---check-out---> another dummy WS > ---post-check-out-treatment-(git-smudge)---> WS You might be able to do this kind of thing with git. But I doubt you'll get it working nicely with Subversion. Why don't you use git? Now that I know more details, it seems that git's solution fits your problem much better. It is not something we can easily add to svn because we don't have a separate stage between the working copy and the repository. It seems something like that would need to be added to svn first. > As code in each developper WS is not standard, I cannot diff code > from a WS and the repository directly. Files have to be in the same > referential. So either I "smudge" the file coming from the > repository before diff-ing it with the file of the WS, either I > "clean" the WS file, before diff-ing it with the repository file. I think that's a horrible solution to the problem. IMO, developers should work as a team, and thus also agree on common coding and quality standards. No technical solution should be used to resolve differences in matters of taste, or worse, cover up mistakes made due to sloppiness. > >Is this information meant for interactive use by developers while > >developing? Or is it some extended information of the sort that > >svn:keywords supports, which is embedded in files you ship to > >customers (outside the version control system)? > Yes, for my 3rd use case, svn:keywords does the trick. Thanks. But > svn:keywords are not enough though to solve my diff paradigm above. It does. Since you have a way to automatically change coding style in files, you can perform that transformation in a diff tool wrapper script. You could write an external diff tool that takes the files from svn, normalises them, and then diffs them.
Re: problem with dialog box uisng Tortoisesvn
Guten Tag Carmit Shiran, am Mittwoch, 12. September 2012 um 13:12 schrieben Sie: > If you look at my example I sent in the previous email, you can see I > filled in the argument= $target_path : > my $target_path = "file:///C:/svn_repos3/trunk/Widget3" > But I'm looking for a way to fill it automatically with the "current > path/tag". > Is it possible? It depends on where you run your command, if its in the current working copy, you may just replace your target with relative paths like in "svn cp . ../somewhere/to/tag". Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.030-2 1001-310 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: problem with dialog box uisng Tortoisesvn
On Sep 12, 2012, at 06:12, Carmit Shiran wrote: > Do you know if there's a way to know what is the current tag I'm working on? > Meaning: If I want to use 'svn copy' on the file I'm working on now without > sending the argument of the source file but only the tag name, is it possible > to send the 'current file path' as the first argument? > For instance, if the user doesn't know on what tag he's working on, assuming > he's not working on the 'trunk' but rather on 'tag= Release_60'. And now he > wants to copy 'Release_60' to 'Release_61'. But he doesn't know he's working > on 'Release_60'. How do I find out using svn command lines? The user runs "svn info" and examines the output to discover what tag he's working on. Usually one wouldn't be "working on" a tag though. Tags are supposed to be considered as read-only entities. You "work on" branches or trunk. > If you look at my example I sent in the previous email, you can see I filled > in the argument= $target_path : > my $target_path = "file:///C:/svn_repos3/trunk/Widget3" > But I'm looking for a way to fill it automatically with the "current > path/tag". > Is it possible? Sure, you could write a script to extract that information out of "svn info".
Re: Git smudge / Clean / Filter alike in Subversion ?
Le 12/09/2012 13:30, Stefan Sperling a écrit : On Wed, Sep 12, 2012 at 11:40:58AM +0200, Laurent Alebarde wrote: So the best way for me woudl be to use a "dummy" workspace copy before commiting, and another one after check-outing : WS ---pre-commit-treatment-(git-clean)---> dummy WS ---commit---> Repository Repository ---check-out---> another dummy WS ---post-check-out-treatment-(git-smudge)---> WS You might be able to do this kind of thing with git. But I doubt you'll get it working nicely with Subversion. Why don't you use git? Now that I know more details, it seems that git's solution fits your problem much better. It is not something we can easily add to svn because we don't have a separate stage between the working copy and the repository. It seems something like that would need to be added to svn first. I do use Git, but I have to use SVN too. The idea above with "pre-commit-treatment-(git-clean)" and "post-check-out-treatment-(git-smudge)" is something outside SVN, or something that encapsulate SVN. As code in each developper WS is not standard, I cannot diff code from a WS and the repository directly. Files have to be in the same referential. So either I "smudge" the file coming from the repository before diff-ing it with the file of the WS, either I "clean" the WS file, before diff-ing it with the repository file. I think that's a horrible solution to the problem. IMO, developers should work as a team, and thus also agree on common coding and quality standards. No technical solution should be used to resolve differences in matters of taste, or worse, cover up mistakes made due to sloppiness. It is a question of taste and point of view. I agree my opinion is not widespread, but I support it. Is this information meant for interactive use by developers while developing? Or is it some extended information of the sort that svn:keywords supports, which is embedded in files you ship to customers (outside the version control system)? Yes, for my 3rd use case, svn:keywords does the trick. Thanks. But svn:keywords are not enough though to solve my diff paradigm above. It does. Since you have a way to automatically change coding style in files, you can perform that transformation in a diff tool wrapper script. You could write an external diff tool that takes the files from svn, normalises them, and then diffs them. Yes, I have to encapsulate everything. Thanks a lot for your help.
Re: Git smudge / Clean / Filter alike in Subversion ?
Le 12/09/2012 13:20, Stefan Sperling a écrit : On Wed, Sep 12, 2012 at 11:41:05AM +0200, Laurent Alebarde wrote: I could find examples of pre-commit hooks, for example to convert indentation from spaces to tabs or the opposite. This is very wrong. Pre-commit hooks are not supposed to modify the content of commit transactions. Doing so causes the working copy and the repository to get out of sync, having conflicting ideas about what was committed. Don't do this! THANKS for the warning ! So I will use a WS dummy copy to perform my strange things with external tools, and use SVN on this copy. Then I could find the lists of available hooks in the documentation. If I am not mistaken, there is no hook available in the opposite direction, say in the check-out process ? No, there are no hooks during checkout. TortoiseSVN has client-side hooks, however. You might be able to leverage those. But I don't know details of how they work. And this would force all developers to use TortoiseSVN. I agree, that would be bad to require it.
svndumpfilter and empty revisions
Hi there, I have received a subversion dump file that contains about 12000 empty revisions. There's only one subdirectory in the dump filter so I figured I could run it through svndumpfilter include subdir --drop-empty-revs --renumber-revs < src.dmp > filtered.dmp and because the empty revs don't contain any nodes they'd get filtered. However, the empty revisions pass through and end up in the filtered dump file. The empty revisions contain only two things, a svn:log property and a svn:date property. Is this a bug? -Dave
Re: Limiting Subversion noise in apache logs
I have not tried it, but couldn't you do this easier by using the Apache
piped logs feature? Just send the log entries via a pipe to a script that
filters out any entries you do not want in the log. I am not positive, but
your script might even be able to write the entries you filter into a
different file.
Example: http://www.sudleyplace.com/pipederrorlogs.html
On Tue, Sep 11, 2012 at 5:45 PM, wrote:
> I've always been slightly annoyed with Apache 401 "unauthorized" log
> entries
> when accessing a Subversion repository. I realize these are part of the
> standard authentication "handshake" via the http protocol.
> (Always ask anonymously first...)
>
> I also realize that mod_dav_svn can now provide a custom log file, but I
> like
> my apache logs. On a busy server, these can get to be tens of gigabytes
> per
> day. I'm not aware of a way to limit log entries based upon return status
> codes...
>
> As a test, I think I have been able to abuse the rewrite_module to get rid
> of these apache 401 log entries and I was wondering if any
> Apache/Subversion
> gurus could poke holes in why this either doesn't work or shouldn't be
> used:
>
>
>
> # Do not log authentication required responses
> RewriteEngine On
> RewriteCond %{REQUEST_METHOD} OPTIONS
> RewriteCond %{LA-U:REMOTE_USER} =""
> RewriteCond %{REQUEST_URI} !-U
> RewriteRule .* - [Last, ENV=dontlog:1]
>
>
>
> LogFormat "%h %l %u %t \"%r\" %>s %b" common
> CustomLog "logs/access.log" common env=!dontlog
>
>
>
> I'm aware the sub-request for the last RewriteCond line is expensive. I'm
> hopeful the other RewriteCond lines would short circuit most of the server
> accesses. Does Subversion create any connections with something
> other than an initial OPTIONS request? I only trivially tested neon. I
> added
> that condition as a hopeful performance improvement.
>
> And yes, as I stated above, I realize Subversion can create it's own
> custom log, but using that removes the fun in this experiment...
>
> Kevin R.
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Problem with merging
Hello I started using subversion a while back and doing a merge I lost a bunch of source code which prohibited me from updating production for weeks. I now have a stable code base and wish to use subversion so I tried to follow chapter 4, branching and merging. It failed. I was hoping someone could tell me what I am doing wrong. I went through the process twice and got the same result, so at least I make the same mistake consistently. There are a couple of weird unexplained behaviors I am noting along with a log of what I did. 1) I was on revision 4. I then branced it, made a change and it jumped to revision 7. Why? Does the revision apply to all folders under a repository? 2) I made a change to the branch, commited it to revision 6. Then made a change to the trunk to revision 7 (from 4). Then I tried to merge the change from the trunk to the branch and it required an update. Why? 3) Now it says text conflict. What does that mean? Is there another section in the book that may explain merging? Another read? I would like to get subversion working without any more code loss. Here's what I did: 1. Create repository on the server called "test" with trunk and branches directories. 2. Issue the command G:\Code\st>svn checkout https://server.com/svn/test/trunk . 3. Added the project using tortoise (14 files/directories). 4. Made a change to the project. 5. Issue the command G:\Code\st>svn commit -m "Two" Adding WindowsApplication1 Adding WindowsApplication1\Form1.Designer.vb Adding WindowsApplication1\Form1.resx Adding WindowsApplication1\Form1.vb Adding WindowsApplication1\My Project Adding WindowsApplication1\My Project\Application.Designer.vb Adding WindowsApplication1\My Project\Application.myapp Adding WindowsApplication1\My Project\AssemblyInfo.vb Adding WindowsApplication1\My Project\Resources.Designer.vb Adding WindowsApplication1\My Project\Resources.resx Adding WindowsApplication1\My Project\Settings.Designer.vb Adding WindowsApplication1\My Project\Settings.settings Adding WindowsApplication1\WindowsApplication1.sln Adding WindowsApplication1\WindowsApplication1.vbproj Transmitting file data Committed revision 2. 6. Made a change to the project. 7. Issue the command G:\Code\st>svn commit -m "Three" SendingWindowsApplication1\Form1.Designer.vb Transmitting file data . Committed revision 3. 8. Made a change to the project to simulate a feature. 9. Issue the command G:\Code\st>svn commit -m "Four" SendingWindowsApplication1\Form1.Designer.vb Transmitting file data . Committed revision 4. 10. Issue the command G:\Code\st>svn copy https://server.com/svn/test/trunk https://server.com/svn/test/branches/feature -m "Feature" Committed revision 5. 11. Changed the current directory from st (subversion test) to stb (subversion test branch. 12. Issue the command G:\Code\stb>svn checkout https://server.com/svn/test/branches/feature . AWindowsApplication1 AWindowsApplication1\WindowsApplication1.vbproj AWindowsApplication1\Form1.resx AWindowsApplication1\Form1.Designer.vb AWindowsApplication1\Form1.vb AWindowsApplication1\WindowsApplication1.sln AWindowsApplication1\My Project AWindowsApplication1\My Project\Resources.Designer.vb AWindowsApplication1\My Project\Settings.settings AWindowsApplication1\My Project\AssemblyInfo.vb AWindowsApplication1\My Project\Settings.Designer.vb AWindowsApplication1\My Project\Application.Designer.vb AWindowsApplication1\My Project\Application.myapp AWindowsApplication1\My Project\Resources.resx Checked out revision 5. 13. Made a change to the feature branch. 14. Issue the command G:\Code\stb>svn commit -m "Six-feature" SendingWindowsApplication1\Form1.Designer.vb Transmitting file data . Committed revision 6. 15. Changed the current directory from stb to st. 16. Made a change to the project to simulate a bug fix. 17. Issue the command G:\Code\st>svn commit -m "Five-bug fix" SendingWindowsApplication1\Form1.Designer.vb Transmitting file data . Committed revision 7. *** Why 7? 18. Changed the current directory from st to stb to try to merge the bug fix to the feature branch. 19. Issue the command G:\Code\stb>svn merge https://server.com/svn/test/trunk --dry-run svn: E195020: Cannot merge into mixed-revision working copy [5:6]; try updating first *** Why update? No one else is doing anything!! 20. Issue the command G:\Code\stb>svn update Updating '.': At revision 7. *** Why go to 7? 21. Issue the command G:\Code\stb>svn diff -r6:7 (Nothing returned using -r5:7 displays the changes I made) 22. Issue the command G:\Code\stb>svn merge https://server.com/svn/test/trunk --dry-run --- Merging r5 through r7 into '.': CWindowsApplication1\Form1.Designer.vb
Re: Limiting Subversion noise in apache logs
> I have not tried it, but couldn't you do this easier by using the
> Apache piped logs feature? Just send the log entries via a pipe to
> a script that filters out any entries you do not want in the log. I
> am not positive, but your script might even be able to write the
> entries you filter into a different file.
>
> Example: http://www.sudleyplace.com/pipederrorlogs.html
This is an option, but I'm already piping logs to cronolog for log
rotation.
I was also trying to come up with a multi-platform approach, since I
wanted to support both Windows and Unix. I've found the Windows
piped logs to get a little temperamental if you try and get too fancy...
Kevin R.
> On Tue, Sep 11, 2012 at 5:45 PM, wrote:
> I've always been slightly annoyed with Apache 401 "unauthorized" log
entries
> when accessing a Subversion repository. I realize these are part of the
> standard authentication "handshake" via the http protocol.
> (Always ask anonymously first...)
>
> I also realize that mod_dav_svn can now provide a custom log file, but I
like
> my apache logs. On a busy server, these can get to be tens of gigabytes
per
> day. I'm not aware of a way to limit log entries based upon return
status
> codes...
>
> As a test, I think I have been able to abuse the rewrite_module to get
rid
> of these apache 401 log entries and I was wondering if any
Apache/Subversion
> gurus could poke holes in why this either doesn't work or shouldn't be
used:
>
>
>
> # Do not log authentication required responses
> RewriteEngine On
> RewriteCond %{REQUEST_METHOD} OPTIONS
> RewriteCond %{LA-U:REMOTE_USER} =""
> RewriteCond %{REQUEST_URI} !-U
> RewriteRule .* - [Last, ENV=dontlog:1]
>
>
>
> LogFormat "%h %l %u %t \"%r\" %>s %b" common
> CustomLog "logs/access.log" common env=!dontlog
>
>
>
> I'm aware the sub-request for the last RewriteCond line is expensive.
I'm
> hopeful the other RewriteCond lines would short circuit most of the
server
> accesses. Does Subversion create any connections with something
> other than an initial OPTIONS request? I only trivially tested neon. I
added
> that condition as a hopeful performance improvement.
>
> And yes, as I stated above, I realize Subversion can create it's own
> custom log, but using that removes the fun in this experiment...
>
> Kevin R.
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
Re: Problem with merging
On Wed, Sep 12, 2012 at 01:39:41PM -0400, John Maher wrote: > Here's what I did: Hi John, your questions are about fundamental Subversion concepts, and that's fine. Just please understand that I don't want to type another explanation since good documentation has already been written. So, below, I'll throw you some links to the FAQ and the Subversion book for further reading, hoping that these will answer your questions. > 1.Create repository on the server called "test" with trunk and > branches directories. > 2.Issue the command G:\Code\st>svn checkout > https://server.com/svn/test/trunk . > 3.Added the project using tortoise (14 files/directories). > 4.Made a change to the project. > 5.Issue the command G:\Code\st>svn commit -m "Two" > Adding WindowsApplication1 > Adding WindowsApplication1\Form1.Designer.vb > Adding WindowsApplication1\Form1.resx > Adding WindowsApplication1\Form1.vb > Adding WindowsApplication1\My Project > Adding WindowsApplication1\My Project\Application.Designer.vb > Adding WindowsApplication1\My Project\Application.myapp > Adding WindowsApplication1\My Project\AssemblyInfo.vb > Adding WindowsApplication1\My Project\Resources.Designer.vb > Adding WindowsApplication1\My Project\Resources.resx > Adding WindowsApplication1\My Project\Settings.Designer.vb > Adding WindowsApplication1\My Project\Settings.settings > Adding WindowsApplication1\WindowsApplication1.sln > Adding WindowsApplication1\WindowsApplication1.vbproj > Transmitting file data > Committed revision 2. > 6.Made a change to the project. > 7.Issue the command G:\Code\st>svn commit -m "Three" > SendingWindowsApplication1\Form1.Designer.vb > Transmitting file data . > Committed revision 3. > 8.Made a change to the project to simulate a feature. > 9.Issue the command G:\Code\st>svn commit -m "Four" > SendingWindowsApplication1\Form1.Designer.vb > Transmitting file data . > Committed revision 4. > 10. Issue the command G:\Code\st>svn copy > https://server.com/svn/test/trunk > https://server.com/svn/test/branches/feature -m "Feature" > Committed revision 5. > 11. Changed the current directory from st (subversion test) to stb > (subversion test branch. > 12. Issue the command G:\Code\stb>svn checkout > https://server.com/svn/test/branches/feature . > AWindowsApplication1 > AWindowsApplication1\WindowsApplication1.vbproj > AWindowsApplication1\Form1.resx > AWindowsApplication1\Form1.Designer.vb > AWindowsApplication1\Form1.vb > AWindowsApplication1\WindowsApplication1.sln > AWindowsApplication1\My Project > AWindowsApplication1\My Project\Resources.Designer.vb > AWindowsApplication1\My Project\Settings.settings > AWindowsApplication1\My Project\AssemblyInfo.vb > AWindowsApplication1\My Project\Settings.Designer.vb > AWindowsApplication1\My Project\Application.Designer.vb > AWindowsApplication1\My Project\Application.myapp > AWindowsApplication1\My Project\Resources.resx > Checked out revision 5. > 13. Made a change to the feature branch. > 14. Issue the command G:\Code\stb>svn commit -m "Six-feature" > SendingWindowsApplication1\Form1.Designer.vb > Transmitting file data . > Committed revision 6. > 15. Changed the current directory from stb to st. > 16. Made a change to the project to simulate a bug fix. > 17. Issue the command G:\Code\st>svn commit -m "Five-bug fix" > SendingWindowsApplication1\Form1.Designer.vb > Transmitting file data . > Committed revision 7. > *** Why 7? See http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.revs and http://subversion.apache.org/faq.html#globalrev Note that the "tree" being talked about there is not an individual branch, but all nodes in the repository, including the /trunk directory and the /branches/feature directory. > 18. Changed the current directory from st to stb to try to merge the > bug fix to the feature branch. > 19. Issue the command G:\Code\stb>svn merge > https://server.com/svn/test/trunk --dry-run > svn: E195020: Cannot merge into mixed-revision working copy [5:6]; try > updating first > *** Why update? No one else is doing anything!! Please see http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs and http://subversion.apache.org/faq.html#hidden-log > 20. Issue the command G:\Code\stb>svn update > Updating '.': > At revision 7. > *** Why go to 7? See above. > 21. Issue the command G:\Code\stb>svn diff -r6:7 > (Nothing returned using -r5:7 displays the changes I made) > 22. Issue the command G:\Code\stb>svn merge > https://server.com/svn/test/trunk --dry-run > --- Merging r5 through r7 into '.': > CWindowsApplication1\Form1.Designer.vb > Summary of conflicts: > Text conflicts: 1 > What does that mean? See http://svnbook.red-b
Re: Problem with merging
Guten Tag John Maher, am Mittwoch, 12. September 2012 um 19:39 schrieben Sie: > I started using subversion a while back and doing a merge I lost a bunch > of source code which prohibited me from updating production for weeks. Unless you didn't commit, you can't loose source code, that's what version control is all about. Even if you didn't commit Subversion would always try everything to preserve your current modifications, which may result in the conflicts you describe later. The easiest way to never ever loose anything it always commit before doing any changes to your working copy like merges and whatever goes wrong after a commit can be restored. > I now have a stable code base and wish to use subversion so I tried to > follow chapter 4, branching and merging. It failed. If you mean your later mentioned conflicts with "failed", this isn't exactly true, as a conflict is a normal operation and the merge may succeed. Conflicts only mean that there are changes which Subversion can't merge automatically safely and the user needs to do something to merge the changes. This is not the same as an error during the merge or else. > 1) I was on revision 4. I then branced it, made a change and it > jumped to revision 7. Why? Does the revision apply to all folders > under a repository? Yes, revisions are global, that's one of the fundamental concepts of Subversion and is normally considered as a major benefit over previous centralized version control like CVS. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.030-2 1001-310 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
cvs2svn failing on "non-CVS" files
I'm helping upgrade a 12 year old CVS repository to use modern source control, and have run into a bit of a surprise. Running either cvs2svn or cvs2git, I'm finding a couple of old CVS files that were hand edited, 6 hears, and cause cvs2svn to fail with this kind of error. /data/cvs/tusk/ocw/tmpl/Attic/header,v Processed 5345 files Pass 1 complete. === Error summary: ERROR: '/var/www/cvs/module/badfile,v' is not a valid ,v file This is with cvs2svn 2.3.0, Subversion 1.6.12 on Ubuntu or Subversion 1.6.11 on RHEL. I've also tested with Subvesion 1.7.4 on RHEL, same problem. My problem is that the CVS files check out OK with plain CVS, and my clients really want to keep the history intact in their migration. Has anyone had fun and experience with CVS files that work in CVS, but break cvs2svn? Are there any particular pointers? Any guidelines on repairing such mangled files?
