Re: software distribution with subversion
Guten Tag Jason Keltz, am Donnerstag, 31. Januar 2013 um 23:10 schrieben Sie: > Any ideas that anyone might be able to offer? As it seems most answers vote against using Subversion and use rsync or some alternative instead, I would like to add some ideas which vote for Subversion because I use a similar approach like yours with one of our products some of my customers. It's not about 60 GB of data, though, only around 75 MB per client, but each client needs some little customizations, for example. In my environment my customers use SSH to establish a tunnel to access a special svnserve instance only serving binary data which can directly be used without installation or else. It's just a simple directory structure which is in most cases saved on a file server of a customer and used by it's own clients from there. I found this to work quite well as it's an easy and flexible setup. Some of my customers use this access to get the data and build customized MSI installation packets for Windows on their own. 1. rsync files to deployment server Besides the reasons not running svnserve on the file server itself, why don't you seem to consider running the working copy for your trunk or whatever will be the source for your deployment server on the file server? This would need more space on the file server, of course, but it would save you the rsync to the deployment server and the working copy on the deployment server. How are changes to the directory structure on the file server applied at all? If it is from users, they could already use Subversion clients to apply those changes and could deal with moves, renames, deletes etc. in the proper Subversion way which would provide full tracking and history of the changes. 2. repo size Depending on your data, Subversions representation sharing of content could save you a lot of repo space. While the clients still had to deal with pristine copies etc., the needed space for your deployment server may be a lot less than your mentioned 60 GB. Another good thing on representation sharing is that it works on a per repo basis, not e.g. per directory, which means that even if you branch a lot of clients for any reason and each client needs to get updated binaries the total amount of space needed won't scale with the number of clients branched, but only with the different binary changes committed, which could be a lot less in an environment were all clients need to have the same binaries. 3. customizations for some clients You descriptions reads like each and every client has exactly the same data set to fetch. What's the chance for exceptions and that some clients need special binaries, configuration files or whatever for some reasons? With a "simple" rsync approach this would really complicate your setup as you would need another directory structure with full data or need to symlink some parts of your directory structure or whatever. Using subversion you could easily, fast and efficient branch the clients which need customizations and if you use working copies on the file server your users could easily apply those customizations and see which customizations are made. This would make your maintenance life much easier than generating a diff between do directory structures which are used as a rsync basis. 4. updates by revision Depending on the size of your changes, I agree that using Subversion for updates will be much more efficient than running rsync and letting it calculate the needed changes. It's not a matter of if rsync will be slower but only how slow it will perform and if this would be a real problem in environment or not. But from my point of view it a simple space vs. processing time if you look at Subversion vs. rsync. 5. pristine space needed on clients You didn't seem to mention what kind of clients you need to update. Depending on their kind the doubled space for pristine copies may not even be a problem at all. 6. Server access and security Did you already think of security, is there any need to secure clients against each other at all? Using rsync and especially customizatioins you would maybe need to create a lot of users and or groups and use security on the file system and OS level. Subversion provides it's own configuration which may even be versioned itself for documentations purposes etc. 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...05151- 9468- 55 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
Revision or date of a svn:external property
Hello World, I am trying to find out, when (revision or date) a svn:external property was set or changed. I am on a Windows 7 Professional and have a few unix commands installed... But a simple svn log | grep external did not what I intended... How can I find out? Thank you and best regards Freundliche Grüsse WENZEL Metromec AG Andreas Tscharner -- Andreas Tscharner, Development WENZEL Metromec AG, Rheinfelsstrasse 1, CH-7007 Chur, Switzerland phone: +41 (0)81 257 07 00 fax:+41 (0)81 257 07 01 e-mail: mailto:andreas.tschar...@metromec.ch www:http://www.metromec.ch
Re: file externals inside directory externals trouble in 1.6 not 1.7 ?
On Fri, Feb 1, 2013 at 12:16 AM, Ward Willats wrote: > Hello. > > I setup some directory and file externs to prune the boost C++ library tree > for our projects. > > Like this: > > http://repo/boost/boost_dir/ boost/boost_dir/ > http://repo/boost/boostfile.cpp boost/boost_file.cpp > > (only a lot more complicated) > > That is, I used directory externals to create the boost/subdirectories from > the boost tree in the working copy, and the file externals to pepper the > top-level boost files into boost/. > > Worked great in my 1.7.0 client with new working copy format. Told all my > co-workers to "come and get it!" Said co-workers are using various 1.6.x > clients, BUT, while they got the directory externs they got NONE of the file > externs. (In the case of 1.6.11 -- I think -- it complained the top-level > boost external was "not a working copy.") > > I guess I want to know WTF? -- since the docs say file externs are supported > in 1.6 and up. Was this sort of nesting broken originally? If so, when was it > fixed? Or is it because I am using the new 1.7 working copy format things are > good for me? > I suppose this is one of the (many) problems that was fixed by 1.7's new working copy format (WC-NG). I suggest that all your users (that need to work with this nested externals structure) upgrade to 1.7 as soon as possible. I quickly searched the issue tracker for issues with the word "external" in the summary, which were fixed in a 1.7 release [1]. There are 32 such issues :-). Maybe if you go through that list you'll find the one that causes your problem ... (or it might be yet another problem with externals that was fixed by wcng, but was not yet known in the issue tracker). [1] http://subversion.tigris.org/issues/buglist.cgi?component=subversion&issue_status=RESOLVED&issue_status=VERIFIED&issue_status=CLOSED&target_milestone=1.7.x&target_milestone=1.7.9&target_milestone=1.7.8&target_milestone=1.7.7&target_milestone=1.7.6&target_milestone=1.7.5&target_milestone=1.7.4&target_milestone=1.7.3&target_milestone=1.7.2&target_milestone=1.7.1&target_milestone=1.7.0&target_milestone=1.7-consider&short_desc=external&short_desc_type=substring -- Johan
Re: FreeBSD project and subversion.
On 1/31/13 12:08 PM, Stefan Sperling wrote:
On Thu, Jan 31, 2013 at 10:37:14AM -0500, Alfred Perlstein wrote:
FreeBSD has moved to Subversion a few years ago and it's worked
very, very well for us.
Thanks! That's encouraging to hear.
The one area where we are having issues is merging code from project
branches back into trunk.
The typical workflow is:
1) create project branch.
2) code code code.
3) sync from HEAD (this works great).
4) repeat steps 2+3 until feature is complete.
5) svn diff and apply to head then commit.
Is there a way to do 5 automatically?
I think the worry is mergeinfo from the project branch coming back
into HEAD.
Any tips would be appreciated.
I've read the FreeBSD svn merging docs some time ago. I'm not sure if
changes have been made since, but it was probably an older version
of what currently lives at this URL:
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html
Back then I was somewhat worried that apparently the person who wrote them
didn't really understand much about how merges in Subversion work.
There was irrational fear of mergeinfo propagation, to the point where
the recommended practice is to remove mergeinfo before commit, which
any Subversion user with a clue will know is very wrong (expect in very
exceptional circumstances and only if you are equipped with sufficient
expertise to deal with the consequences).
What surprised me also was a complete lack of mention of the --reintegrate
option, which I suspect must be causing quite a lot of grief among FreeBSD
developers due to bogus conflicts during merges back into FreeBSD's head
branch (i.e. the trunk).
We'll need more details to help you in a constructive way, though.
Can you provide more details about your steps 1 to 5, i.e. show the
exact commands you're running in each step? The repository is public,
after all, which will help greatly with identifying and reproducing
specific problems.
I'm happy to provide input for improving FreeBSD's docs to the point
where FreeBSD makes the best possible use of Subversion 1.7's merge
implementation, and can also provide some hints as to how future versions
of Subversion will improve to make life easier in certain cases.
BTW, I went over one of FreeBSD's svn wiki pages a while back, and added
answers to open questions on this page:
https://wiki.freebsd.org/SubversionMissing
Thank you Stefan,
So I have two answers here:
1) about mergeinfo
It seems as if doing it all at the top can make merges over long haul
internet very painful.
2) about reintegrate
I've attached the two messages that show what makes FreeBSD gun shy
about merges to HEAD.
Maybe these issues are resolved, or maybe the developer did something
incorrect, or maybe something else entirely different happened.
See attached.
Thank you,
-Alfred
--- Begin Message ---
--
John Baldwin
--- Begin Message ---
On Friday, June 01, 2012 1:40:29 pm David O'Brien wrote:
> On Wed, May 16, 2012 at 11:00:48AM -0400, John Baldwin wrote:
> > I more or less don't trust svn merge to DTRT here. This was done with
> > the cpuset branch merge up to HEAD and it broke the log history of many
> > files in HEAD.
>
> Specifically how did it break log history?
http://svnweb.freebsd.org/base/head/share/man/man4/geom_map.4?view=log
You have to walk up to the previous directory in svnweb and go back to
change 222812 and then click on geom_map.4 to find its original log.
sys/dev/iicbus/ad7417.c was also busted this way.
> > I would just generate a diff and manually apply that to
> > a HEAD checkout and commit that. You could perhaps svn cp over new files
> > from the nand branch to HEAD to preserve their history, but I worry that
> > anything other than diff + patch for existing files risks hosing history.
>
> WOAH!! Please lets gain some new experience with 'svn merge' using
> version 1.7. We do 100's of merges a year at $WORK (with svn 1.6)
> on a code base 10x that of FreeBSD -- it works.
I've never had problems with merging downstream into work branches. I've
only seen upstream merges blow up.
--
John Baldwin
--
This mail is for the internal use of the FreeBSD project committers,
and as such is private. This mail may not be published or forwarded
outside the FreeBSD committers' group or disclosed to other unauthorised
parties without the explicit permission of the author(s).
--- End Message ---
--- End Message ---
--- Begin Message ---
On Friday, February 01, 2013 7:53:57 am Alfred Perlstein wrote:
> John and Peter, both of you are +inf more knowledgeable about svn than I am.
>
> I see we still try to minimize svn mergeinfo from the FAQ ("Selecting
> the Source and Target")
> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-
guide/subversion-primer.html#AEN771
>
> I know I've seen some emails explaining the reasoning behind this but I
> can't find them. What would the effect of bringing mergeinfo to the top be?
>
> Possible pr
Re: software distribution with subversion
The OP isn't subscribed and so probably didn't see your reply. Branko Čibej wrote on Fri, Feb 01, 2013 at 00:37:41 +0100: > I expect you've considered this option, but just to add it to the list:
AW: Commit Error in conversion of types
I have seen random client-side disk IO errors when our virus scanner interfered with the sqlite library used in subversion 1.7, when massive log file activity triggered a bug (which is still not fixed) in the behavioural analysis module of the virus scanner. Try to disable the virus scanner (at least for the .svn directory) or try a subversion 1.6 client which does not use sqlite. I can send you some detailed information and a test application if you are interested. Mit freundlichen Grüßen Dr. Hartmut Niemann Von: Julio Palma [mailto:ju...@sigcorp.com.br] Gesendet: Donnerstag, 24. Januar 2013 21:44 An: users@subversion.apache.org Betreff: Commit Error in conversion of types Hi, Subversion community, [...] Some of selected resources were not committed. Some of selected resources were not committed. svn: E200030: Commit failed (details follow): svn: E200030: Commit failed (details follow): svn: E200030: disk I/O error svn: E200030: disk I/O error svn: E200029: Couldn't perform atomic initialization [...]
Re: software distribution with subversion
Thanks to everyone who provided me with very helpful feedback re: my problem of "software distribution with subversion". I am re-evaluating the project, and how to complete it best. Thanks! Jason.
Re: svn:externals - svn: E200009: Targets must be working copy paths
Ryan: I was able to set multiple external definitions using the --file option. Worked pretty well, actually considering how challenging everything else has been so far! One last question on this topic. I want to pin the external definition to a known revision using something this shortened command, but it's not working. The "-r 109" being the revision I want to pin to. c:\Temp\800>svn propset svn:externals -r 109 . svn: E205000: Cannot specify revision for setting versioned property 'svn:externals' Andreas: I will provide feedback on the documentation shortly. On Wed, Jan 30, 2013 at 4:38 PM, Ryan Schmidt < subversion-20...@ryandesign.com> wrote: > > On Jan 30, 2013, at 14:14, C M wrote: > > > Thank you for the "teach a man to fish" approach. Though I didn't find > the documentation to be very clear, I was able to set the property using > the syntax below. > > > > > > c:\Temp\800>svn propset svn:externals "ver_1.0 > svn://3.x.x.x/trunk/Customer1/system_800/ver_1.0" . > > property 'svn:externals' set on '.' > > > > This worked for the directory listed above. I then added several > external definitions, but when I finally committed and checked out, it > seems that only the last definition was applied. Evidently I overwrote the > previous definitions. > > > > Can I add multiple external definitions? If it's in the "svn help > propset", I am not seeing it. > > Yes you can have multiple externals definitions, one on each line of the > svn:externals property. Setting a multiline property on the command line > via "svn propset" is difficult, so instead try "svn propedit svn:externals > ." (and type the multiline externals into the interactive editor) or "svn > propset svn:externals --file X ." (and provide a file X containing the > multiline externals). > > >
Re: Commit Error in conversion of types
Hi, Dr. Hartmut, Thank for your tips, but the problem in my company was the type of filesystem that I use for the build the SVN project. After this, I changed and I migrated the repositories and don't happened again, but I agree with your tip and I go to verify this possibility and stay attent. Thanks lot, JC 2013/2/1 Niemann, Hartmut > I have seen random client-side disk IO errors when our virus scanner > interfered with the > sqlite library used in subversion 1.7, when massive log file activity > triggered a bug > (which is still not fixed) in the behavioural analysis module of the virus > scanner. > > Try to disable the virus scanner (at least for the .svn directory) > or try a subversion 1.6 client which does not use sqlite. > > I can send you some detailed information and a test application if you are > interested. > > > > Mit freundlichen Grüßen > Dr. Hartmut Niemann > > > > > > Von: Julio Palma [mailto:ju...@sigcorp.com.br] > Gesendet: Donnerstag, 24. Januar 2013 21:44 > An: users@subversion.apache.org > Betreff: Commit Error in conversion of types > > > Hi, Subversion community, > > > [...] > Some of selected resources were not committed. > Some of selected resources were not committed. > svn: E200030: Commit failed (details follow): > svn: E200030: Commit failed (details follow): > svn: E200030: disk I/O error > svn: E200030: disk I/O error > svn: E200029: Couldn't perform atomic initialization > > [...] > > > >
Re: "svn info" does not work with symlink to different working copy
Michael Kaufmann wrote on Thu, Jan 31, 2013 at 14:06:08 +0100: > Hi all, > > I am using Subverison 1.7.8. On my disk are two Subversion working copies > (from different repositories), and one working copy contains a symlink to the > other: > > I have not found anything about this behavior in the bug tracker. > Is this "by design" or is it a Subversion bug? I'm pretty sure there's an issue filed for this already. I'd have expected a search for "symlink" to turn it up. The whole topic of 'symlink to working copy' (and whether the symlink itself is versioned of not) is... fun. Maybe it's better in 1.8 than in 1.7? I didn't follow development in that area closely.
Re: Default values for args to svn_cmdline_create_auth_baton
Hi again! Ryan Vordermann wrote on Thu, Jan 31, 2013 at 13:01:19 -0700: > Hi, > > My name is Ryan. I'm not subscribed to this list so I would appreciate > being CC'ed on responses > > I'm working on a utility that uses the svn client api. Right now it works, > but I want to add support for usernames and passwords. I do not (yet) Have a look at subversion/tests/cmdline/atomic-ra-revprop-change.c . It supports exactly providing a (single, known-in-advance) username/password pair. > want to support any of the other security features. What are the > appropriate values for the following arguments to this function? > > svn_cmdline_create_auth_baton > > Currently I have this: > svn_boolean_t non_interactive = FALSE; Basically this is "may prompt". The "plaintext" and "SSL certificate" prompt depend on this. > const char *config_dir = NULL; > svn_boolean_t no_auth_cache = FALSE; > svn_boolean_t trust_server_cert = FALSE; Like the corresponding arguments to the cmdline binary. > svn_config_t *cfg_config = NULL; > That's the parsed "config" file from CONFIG_DIR. I'm not quite sure why we have both this and 'const char *config_dir'. (Also, where do you see the name "cfg_config"? It's called "cfg" at the declaration and definition, in trunk.) > Which so far works, but I was just taking a WAG. > Did you read the API documentation? Was it not clear? > Thanks in advance, > Ryan Vordermann
Re: svn:externals - svn: E200009: Targets must be working copy paths
On Feb 1, 2013, at 11:00, C M wrote: > I was able to set multiple external definitions using the --file option. > Worked pretty well, actually considering how challenging everything else has > been so far! > > One last question on this topic. I want to pin the external definition to a > known revision using something this shortened command, but it's not working. > The "-r 109" being the revision I want to pin to. > > c:\Temp\800>svn propset svn:externals -r 109 . > > svn: E205000: Cannot specify revision for setting versioned property > 'svn:externals' The revision number to which you want to pin each external needs to be listed on the corresponding line of the svn:externals property. Read the documentation again; I recommend following the example after the paragraph which starts "Or, making use of the peg revision syntax". http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html
Re: svn:externals - svn: E200009: Targets must be working copy paths
On Feb 1, 2013, at 12:24, Ryan Schmidt wrote: > On Feb 1, 2013, at 11:00, C M wrote: > >> I was able to set multiple external definitions using the --file option. >> Worked pretty well, actually considering how challenging everything else has >> been so far! >> >> One last question on this topic. I want to pin the external definition to a >> known revision using something this shortened command, but it's not working. >> The "-r 109" being the revision I want to pin to. >> >> c:\Temp\800>svn propset svn:externals -r 109 . >> >> svn: E205000: Cannot specify revision for setting versioned property >> 'svn:externals' > > The revision number to which you want to pin each external needs to be listed > on the corresponding line of the svn:externals property. Read the > documentation again; I recommend following the example after the paragraph > which starts "Or, making use of the peg revision syntax". > > http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html Or, in the example you gave above of wanting to pull a specific revision of just a single external, you just need quotes: svn propset svn:externals "-r 109 " . Or better yet, using peg revision syntax: svn propset svn:externals "@109" .
Re: Default values for args to svn_cmdline_create_auth_baton
Daniel Shahaf wrote on Fri, Feb 01, 2013 at 19:15:04 +0200: > Hi again! > > Ryan Vordermann wrote on Thu, Jan 31, 2013 at 13:01:19 -0700: > > Hi, > > > > My name is Ryan. I'm not subscribed to this list so I would appreciate > > being CC'ed on responses > > > > I'm working on a utility that uses the svn client api. Right now it works, > > but I want to add support for usernames and passwords. I do not (yet) > > Have a look at subversion/tests/cmdline/atomic-ra-revprop-change.c . It > supports exactly providing a (single, known-in-advance) > username/password pair. I should clarify, though: that tool uses the svn_ra_* API directly, bypassing the (higher-level) svn_client_* API. Your tool might or might not want to do that.
Re: svn:externals - svn: E200009: Targets must be working copy paths
Ryan Schmidt wrote on Fri, Feb 01, 2013 at 12:29:32 -0600: > > On Feb 1, 2013, at 12:24, Ryan Schmidt wrote: > > > On Feb 1, 2013, at 11:00, C M wrote: > > > >> I was able to set multiple external definitions using the --file option. > >> Worked pretty well, actually considering how challenging everything else > >> has been so far! > >> > >> One last question on this topic. I want to pin the external definition to > >> a known revision using something this shortened command, but it's not > >> working. The "-r 109" being the revision I want to pin to. > >> > >> c:\Temp\800>svn propset svn:externals -r 109 . > >> > >> svn: E205000: Cannot specify revision for setting versioned property > >> 'svn:externals' > > > > The revision number to which you want to pin each external needs to be > > listed on the corresponding line of the svn:externals property. Read the > > documentation again; I recommend following the example after the paragraph > > which starts "Or, making use of the peg revision syntax". > > > > http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html > > Or, in the example you gave above of wanting to pull a specific revision of > just a single external, you just need quotes: > > svn propset svn:externals "-r 109 " . > You need a '--' argument here to prevent an argument parsing error. svn propset -- svn:externals "-r 109 " ./ > Or better yet, using peg revision syntax: > > svn propset svn:externals "@109" . > >
Re: Revision or date of a svn:external property
On Feb 1, 2013, at 02:53, Andreas Tscharner wrote: > I am trying to find out, when (revision or date) a svn:external property was > set or changed. > > I am on a Windows 7 Professional and have a few unix commands installed... > > But a simple > svn log | grep external > did not what I intended... "svn log" only shows you the log messages; I guess nobody entered the word "external" into the log message when they added that external. What you want is "svn log --diff", which will show you the log message and also what changed. It's available since Subversion 1.7.
Re: Apache Subversion 1.7.7 - svn log issues
On Jan 31, 2013, at 22:40, Ramachandran Raghavendran wrote: > I performed the very first commit into a repository and I’m running the svn > log command at the file level (svn log -v --xml --stop-on-copy @URL PATH, > where PATH represents a file). > However this syntax lists all the changes to the URL. > Have anybody encountered this behaviour . is this a bug? When you say "@URL", you mean you typed the URL of the repository, right? You didn't actually type "@URL", or an "@" and then a URL? If you want the log of a specific directory or file in the repository, then just list the complete URL of the directory or file inside the repository. For example, the URL of the Subversion repository used by all Apache Software Foundation projects is: http://svn.apache.org/repos/asf To see the log of, say, the configure script of the Apache HTTP Server project, you would do: svn log http://svn.apache.org/repos/asf/httpd/httpd/trunk/configure.in
Resolved: svn:externals - svn: E200009: Targets must be working copy paths
Everything is working now as desired..I can set multiple externals with specific rev numbers attached. Thank you all for your help! Regards. Amad On Fri, Feb 1, 2013 at 12:32 PM, Daniel Shahaf wrote: > Ryan Schmidt wrote on Fri, Feb 01, 2013 at 12:29:32 -0600: > > > > On Feb 1, 2013, at 12:24, Ryan Schmidt wrote: > > > > > On Feb 1, 2013, at 11:00, C M wrote: > > > > > >> I was able to set multiple external definitions using the --file > option. Worked pretty well, actually considering how challenging everything > else has been so far! > > >> > > >> One last question on this topic. I want to pin the external > definition to a known revision using something this shortened command, but > it's not working. The "-r 109" being the revision I want to pin to. > > >> > > >> c:\Temp\800>svn propset svn:externals -r 109 . > > >> > > >> svn: E205000: Cannot specify revision for setting versioned property > 'svn:externals' > > > > > > The revision number to which you want to pin each external needs to be > listed on the corresponding line of the svn:externals property. Read the > documentation again; I recommend following the example after the paragraph > which starts "Or, making use of the peg revision syntax". > > > > > > http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html > > > > Or, in the example you gave above of wanting to pull a specific revision > of just a single external, you just need quotes: > > > > svn propset svn:externals "-r 109 " . > > > > You need a '--' argument here to prevent an argument parsing error. > > svn propset -- svn:externals "-r 109 " ./ > > > Or better yet, using peg revision syntax: > > > > svn propset svn:externals "@109" . > > > > >
adding --include-externals to svn diff
To parallel the additions of --include-externals to the 'commit' and 'ls' commands, I would also like to propose adding the option to the 'diff' command. I just tested latest trunk and the option is unrecognized. Given the discussions around the previously enhanced commands, I think the reason for wanting the continuity is obvious: Developers often do a diff before committing, and it's important they are able to diff at the same scope as they commit. I was inquiring on the IRC channel on some other issues, but got no response. Hence the email to the list :) Let me know what I can do, within reason, to help bring make these commands more congruent for 1.8.0. Thanks!
