Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
Guten Tag Vitor Barata, am Dienstag, 30. Oktober 2012 um 06:58 schrieben Sie: > Maybe I called our system the wrong name. It is a homemade system, and > here are some of the things that it does: Just to be clear: What you call your build system is used directly by the devs and something we can think of as some kind of assistant to get pre configured working copies, right? The devs start this assistant, choose whatever fits their need and afterwards it is checking out, setting up and compiling things etc. and during that process svn working copies are created with versioned files with local modifications which should be ignored in svn status and comparable operations. If I understood correctly and you don't have any naming or directory layout convention to ignore the best chance in my opinion is your "build system", as if it knows what it does automatically and should be ignored it should get capable of providing that information to svn. It could update the user wide configuration for ignore patterns of Subversion or specify paths to exclude for Tortoise 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
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
> Just to be clear: What you call your build system is used directly by > the devs and something we can think of as some kind of assistant to > get pre configured working copies, right? The devs start this > assistant, choose whatever fits their need and afterwards it is > checking out, setting up and compiling things etc. and during that > process svn working copies are created with versioned files with local > modifications which should be ignored in svn status and comparable > operations. That is almost correct. You got the nature of the system right, but it does not create versioned files with local modifications. It creates several unversioned files, which should be ignored as well. These files do not follow any naming or directory layout convention, their names and locations are freely specified as part of each project's specification, which is kept in versioned per-project configuration files. The unversioned files are the main problem. > If I understood correctly and you don't have any naming or directory > layout convention to ignore the best chance in my opinion is your > "build system", as if it knows what it does automatically and should > be ignored it should get capable of providing that information to svn. > It could update the user wide configuration for ignore patterns of > Subversion or specify paths to exclude for Tortoise etc. Yes, indeed, the system knows exactly what should be ignored given the current in-development projects and other configuration options. With CVS, it marked these files as ignored by locally editing the .cvsignore file inside each folder, which did not have any undesired effect. Now, with SVN, our first idea was to locally edit each folder's svn:ignore property. However, since svn:ignore is itself versioned, every folder is always inconveniently marked as locally modified (property change only) by SVN, because the list of ignored files is different depending on the chosen projects and configuration options. And now we're back at my first post, self-quoted below. I can't help but think that there should be an unversioned list of ignored file patterns (.svnignore local file or svn:localignore property or something like that) as well as the versioned svn:ignore property. (self-quote) > The only solution I could think of (to be able to keep a somewhat > stable svn:ignore property) would be to populate the svn:ignore > property with every file that could ever be automatically generated by > the build system when operating in each and every local configuration > scenario. Even then, however, there is still some unnecessary hassle: > > - For the property to be automatically updated, the build system would > have to simulate every possible configuration (lots of possibilities) > to update the svn:ignore property, which is a lot more work that > working only with the single, currently selected configuration. > - The system could get the current svn:ignore property and only add > new items to it based on the currently selected configuration, but > this may result in unnecessarily bloated svn:ignore properties over > time, since no-longer-generated files would never be removed from the > list. > - If the property is to be managed manually, then the developers must > remember to always update the svn:ignore property themselves every > time a new file is automatically generated or an old file ceases to be > generated. This is error-prone and requires every developer to know > about the internals of the build system. > > The second option above is the strongest solution in my opinion, > but it is still more complex than a simple .svnignore file (or an > extra unversioned ignore property), and yet results in a not-as-good > behavior.
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
Guten Tag Vitor Barata, am Dienstag, 30. Oktober 2012 um 14:54 schrieben Sie: > I > can't help but think that there should be an unversioned list of > ignored file patterns (.svnignore local file or svn:localignore > property or something like that) as well as the versioned svn:ignore > property. But there's none and unless you code this feature on your own you won't get it anytime soon, I guess. The only thing left is your build system and the already present configuration for the used Subversion client and TortoiseSVN. 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
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
On Tue, Oct 30, 2012 at 03:35:46PM +0100, Thorsten Schöning wrote: > Guten Tag Vitor Barata, > am Dienstag, 30. Oktober 2012 um 14:54 schrieben Sie: > > > I > > can't help but think that there should be an unversioned list of > > ignored file patterns (.svnignore local file or svn:localignore > > property or something like that) as well as the versioned svn:ignore > > property. > > But there's none and unless you code this feature on your own you > won't get it anytime soon, I guess. The only thing left is your build > system and the already present configuration for the used Subversion > client and TortoiseSVN. > > Mit freundlichen Grüßen, > > Thorsten Schöning Is editing the global-ignores setting in the Subversion configuration file, as already suggested by Thorsten in an earlier post, not an option? That's currently the only unversioned place where ignore settings can be configured. See http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html#svn.advanced.confarea.opts.config Can the build system output its files into a subdirectory with a known name which can then be ignored? It seems your use case is rather exceptional. I've rarely seen the need to ignore arbitrary files with names that aren't known in advance. However, it's clear that the current ignore system isn't well suited for this case, so maybe we should extend Subversion in some way to account for this.
svn diff outout
Hello, Is there a way to get (via cmd line) a list of files that have changed between revisions, instead of the content of the files?
Re: svn diff outout
On 30/10/12 15:39, Ahmed, Omair (GE Oil & Gas) wrote: Hello, Is there a way to get (via cmd line) a list of files that have changed between revisions, instead of the content of the files? svn log -v
Re: svn diff outout
On Tue, Oct 30, 2012 at 11:39:52AM -0400, Ahmed, Omair (GE Oil & Gas) wrote: > Hello, > > > > Is there a way to get (via cmd line) a list of files that have changed > between revisions, instead of the content of the files? Yes, there is: svn diff --summarize -r REV1:REV2 URL
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
> Is editing the global-ignores setting in the Subversion configuration file, > as already suggested by Thorsten in an earlier post, not an option? > > That's currently the only unversioned place where ignore settings can > be configured. See > http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html#svn.advanced.confarea.opts.config > > Can the build system output its files into a subdirectory with a known > name which can then be ignored? A large part of the automatically-generated files contain source-code for language binding (Lua to C, Java to C and others). The system generates these files with .c/.cpp/.h extensions (so they can't be ignored based on the extension), but it does not enforce any convention on their names or on which directory they should go, this is freely configurable in custom project configuration files. This means that right now there is no global pattern that could be used in the global-ignores subversion setting. Now, we _could_ change the system and make it enforce a known subdirectory and/or some naming convention for all the automatically-generated source files. The problem is that, since we are talking about actual source code files and even exported headers (possibly used by developers in other dev teams), this would also require a through verification in all #includes (maybe only includepaths, not sure if it would be enough though) that reference such files in all the code in our repository (and possibly those of other dev teams). It seems a big trouble to go through just because of SVN property modifications. > It seems your use case is rather exceptional. I've rarely seen the need > to ignore arbitrary files with names that aren't known in advance. > However, it's clear that the current ignore system isn't well suited > for this case, so maybe we should extend Subversion in some way to > account for this. The simplest and cleanest way I see to extend Subversion to account for this is to provide another special property, say svn:localignore, that would work exactly like svn:ignore, but that would be unversioned, so that it could be altered by automation systems like ours without making directories be marked as modified. Thanks for your suggestions, Thorsten Schöning, Bob Archer and Stefan Sperling. I'm still deciding the best way to avoid the problem on our side, and I'm still listening to other suggestions as well, but so far I still believe that an unversioned ignore property (or something like that) would be a useful (and harmless) addition to Subversion. I have seen similar feature requests (based on different scenarios) be rejected, though, so I will wait a little longer before I make a new official request.
Re: Editing svn:log property on file
Srdan Dukic wrote on Tue, Oct 30, 2012 at 17:36:57 +1300: > Yes, it was the "svn:log" property on the revision (as opposed to the node) > which was causing the issue. Was able to modify it with the "propset" > command and it has allowed svnsync to continue the sync. > > So, the file to be patched is: > http://svn.apache.org/repos/asf/subversion/trunk/subversion/svnsync/sync.c > > Is it the section that's commented as "Normalize svn:* properties as > necessary." that the error's being thrown? > No. That function just changes the line ending style; a local in-memory manipulation. The error is propagated by the commit editor after the validation code (on the server-side) raises it. The commit editor gets the revprops at the svn_ra_get_commit_editor3() call in main.c and the nodeprops via calls to its change_file_prop() and change_dir_prop() methods. See svn_delta_editor_t's docstring where it talks about possibly async error behaviour. If you consider sending a patch, please read http://subversion.apache.org/patches Thanks Daniel > -- > Srdan Dukic > > On 30 October 2012 17:21, Daniel Shahaf wrote: > > > IIRC svnsync would only complain about revisions add or modify an > > svn:log property --- other changes to files having that property (even > > with a bad value) should sync errorlessly. See validate_revision() in > > subversion/libsvn_repos/fs-wrap.c > > > > Anyway. I suggest you figure out a way to exclude "svn:log" node > > properties from the sync. If there is an easier way to do that than to > > patch change_file_prop() in subversion/svnsync/, I'm sure someone will > > suggest it. > > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 17:15:18 +1300: > > > Hmmm... yes indeed. This does seem to be the case, as the same developer > > > committed the same file, with the same log message in another location, > > and > > > this time the dump/load is not working. > > > > > > Even though the load doesn't throw any errors, when continuing with the > > > svnsync after loading, it starts complaining about UTF-8 again and won't > > > load the version. > > > > > > -- > > > Srdan Dukic > > > > > > On 30 October 2012 17:04, Daniel Shahaf wrote: > > > > > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:58:01 +1300: > > > > > Checked it by examining the contents of the dump file (cat > > [dumpfile]). > > > > > Where I expected to see: > > > > > > > > > > client?\146s > > > > > > > > > > > > > Wrong expectation, dump files never include this syntax. > > > > > > > > > I instead got: > > > > > > > > > > client?s > > > > > > > > > > > > > This doesn't say whether it was a literal question mark (0x3F) in the > > > > file or not. > > > > > > > > > > > > > Then, after copying it over to the slave and running "load", without > > the > > > > > "--bypass-prop-validation" flag, the dump is loaded without any > > errors > > > > > complaining about the encoding of the properties. > > > > > > > > > > -- > > > > > Srdan Dukic > > > > > > > > > > On 30 October 2012 16:51, Daniel Shahaf > > wrote: > > > > > > > > > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:45:36 +1300: > > > > > > > Thanks for that. Using svnadmin "dump" and then "load" worked. > > > > > > > > > > > > > > I didn't even have to pass the "--bypass-prop-validation" option > > to > > > > the > > > > > > > load command, as it seems the non-UTF8 symbols were converted to > > a > > > > "?" by > > > > > > > the dump command. > > > > > > > > > > > > How are you checking that? The 'dump' command doesn't know about > > UTF-8 > > > > > > requirements for property values; it should preserve arbitrary byte > > > > > > sequences. (In other words, the output of 'propget --strict | xxd' > > > > > > should be identical between master and slave.) > > > > > > > > > > > >
Re: Issue while setting up subversion repository on Solaris 5.10
Sapna PB wrote on Tue, Oct 30, 2012 at 11:22:00 +0530: > Hi Team, > > Iam facing an issue while setting up subversion repository on Solaris 5.10 > PFB the steps followed. > > > 1. Execute ‘svnadmin create /data/installs/repo’ > > Give 777 permissions to the files and folders in /data/installs/repo > > 2. Go to the folder /data/installs/repo/conf > > Modify svnserve.conf file > > Uncomment anon-access = read, auth-access = write, password-db = passwd > > Modify passwd file > > Add sapna = sapna as credentials. > > 3. Execute ‘svnserve -d -r /data/installs/repo’ > > 4. Execute ‘svn mkdir svn://10.237.205.46/project’ > > It opens up vi editor. Save and continue. > > It prompts for root password. Provide the password. > What does it prompt for the root password for? > It prompts for username and password. Provide sapna/sapna > > If it prompts for ‘Store password unencrypted?(yes/no)’, provide yes > > > > We are getting the error ‘svn:Network connection closed unexpectedly’ after > the 4th command. > If answering the prompts (two password prompts and a yes/no prompt) takes a long time, the server might abort the connection (presuming the client had exited). You could tcpdump the connection and look for any error messages crossing the wire. Maybe others have better ideas, though. > > > Please help me to resolve this issue. > > > > Regards, > > Sapna P B
RE: svn diff outout
This is command returns a double entry for each of the files which changed between two versions. The Tortoise client displays a single entry. c:\>svn diff --summarize -r 3:7 https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens > c:\temp\rel1.6.txt Do you know why that is happening? -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Tuesday, October 30, 2012 10:52 AM To: Ahmed, Omair (GE Oil & Gas) Cc: users@subversion.apache.org Subject: Re: svn diff outout On Tue, Oct 30, 2012 at 11:39:52AM -0400, Ahmed, Omair (GE Oil & Gas) wrote: > Hello, > > > > Is there a way to get (via cmd line) a list of files that have changed > between revisions, instead of the content of the files? Yes, there is: svn diff --summarize -r REV1:REV2 URL
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
On Tue, Oct 30, 2012 at 01:57:09PM -0200, Vitor Barata wrote: > A large part of the automatically-generated files contain source-code > for language binding (Lua to C, Java to C and others). The system > generates these files with .c/.cpp/.h extensions (so they can't be > ignored based on the extension), but it does not enforce any > convention on their names or on which directory they should go, this > is freely configurable in custom project configuration files. This > means that right now there is no global pattern that could be used in > the global-ignores subversion setting. We do exactly the same thing in Subversion itself, and we do have ignore patterns like *.c and so on within the bindings source directories. There doesn't seem to be any problem with this in our project. This command lists the patterns we use: svn propget -v -R svn:ignore https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings I'm not quite sure if you really understand the impact of svn:ignore. What behaviour are you expecting from the svn:ignore mechanism exactly, and how would the expected behaviour impact your workflow? Just to get a common misconception out of the way: Note that you can add files that match an ignore pattern to version control if you really want to. All ignore patterns do is suppress files from appearing in the output of 'svn status'. And some IDEs use ignore patterns to prevent some unversioned files from being suggested for commit but they should still allow such files to be added to version control. > > It seems your use case is rather exceptional. I've rarely seen the need > > to ignore arbitrary files with names that aren't known in advance. > > However, it's clear that the current ignore system isn't well suited > > for this case, so maybe we should extend Subversion in some way to > > account for this. > > The simplest and cleanest way I see to extend Subversion to account > for this is to provide another special property, say svn:localignore, > that would work exactly like svn:ignore, but that would be > unversioned, so that it could be altered by automation systems like > ours without making directories be marked as modified. Based on past experience, I would guess that this is probably not as simple as you imagine it to be, unfortunately. You are talking about a major feature addition, not some small fix. Subversion has no concept of an unversioned property yet. Such a concept would need to be added first which would require some design and implementation effort. A lot of work would need to be done to make sure this new kind of property interacts well with all other features of the system (status, diff, commit, update, ...). That means writing a lot regression tests to start with. This might turn out to be about as "simple" as the "file external" feature turned out to be. A very simple idea on the surface but very hard to get working correctly in all use cases, and we ended up frantically fixing a lot of new bugs related to the feature over the course of several months.
RE: SVN Tag / Branch question
> Hello, > > We did our first release in SVN today. I used the copy command (shown below) > to copy from /trunk to /tag. Since not everything in /trunk was needed for > this > release, I had to specify the directories which were needed. > > Q1. Is this the normal/correct way of doing things? For the new release, just > the > Docs, MKVIE and Screens dirs. were needed. The others were not. Not sure what you mean by "not needed". However, you don't save anything by not just copying trunk to tag. Since svn uses "cheap copies" copying the full trunk folder doesn't take any more space than copying certain folders. Also, if you released your product from a certain svn revision, aren't ALL the files in that revision part of that release version? > Our repo structure is as follows: > > C>svn list https://X.X.com/svn/muxbopcs_svn/trunk/MUX > > Control/ > Docs/ > MKVIE/ > Screens/ > sem_modbus/ > > Q2. Are we better off using release branches instead of copying to /tags? To svn a copy is a copy. tags and branches are semantic names. In general a tag isn't ever committed to. But, this is only by convention. > Q3. Sometime down the line, if I had to re-create a view of "Release 1.6", do > I > just base my workspace on what's in /tags/release-1.6? Or is there > another/better way of re-creating a prior release? I would copy the tag to a branch and work from the branch. > Q4. I was also expecting /tags to contain just the new files for Release > 1.6. However, that wouldn't be case, right? I have a feeling I am confusing > myself over nothing. Basically, all a copy is, is a pointer to the location that it copied. So, the state of the path you copy to includes everything from the source path. But, once again, it is a cheap copy so no files are really copied. BOb
Re: svn diff outout
On Tue, Oct 30, 2012 at 12:25:59PM -0400, Ahmed, Omair (GE Oil & Gas) wrote: > This is command returns a double entry for each of the files which > changed between two versions. The Tortoise client displays a single > entry. > > c:\>svn diff --summarize -r 3:7 > https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens > https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens > > c:\temp\rel1.6.txt > > Do you know why that is happening? I don't know. It does not do that for me. This command, using a public URL, prints one changed file, which is correct: svn diff --summarize -c 1403696 https://svn.apache.org/repos/asf (-c 1403696 means the same as -r 1403695:1403696) Can you provide a reproduction recipe for your problem that I can try out on my own machine?
Re: svn diff outout
On Tue, Oct 30, 2012 at 05:39:33PM +0100, Stefan Sperling wrote: > On Tue, Oct 30, 2012 at 12:25:59PM -0400, Ahmed, Omair (GE Oil & Gas) wrote: > > This is command returns a double entry for each of the files which > > changed between two versions. The Tortoise client displays a single > > entry. > > > > c:\>svn diff --summarize -r 3:7 > > https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens > > https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens > > > c:\temp\rel1.6.txt > > > > Do you know why that is happening? > > I don't know. It does not do that for me. > > This command, using a public URL, prints one changed file, which is correct: > svn diff --summarize -c 1403696 https://svn.apache.org/repos/asf > > (-c 1403696 means the same as -r 1403695:1403696) > > Can you provide a reproduction recipe for your problem that I can try > out on my own machine? Hmmm, looking closer, maybe the problem is simply that you passed the same URL twice? Each URL you specify is a diff target. So if you pass the same target twice you will see the same diff twice. As per the output of 'svn help diff', I am using this invocation: 1. diff [-c M | -r N[:M]] [TARGET[@REV]...] and *not* this one: 3. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV]
RE: svn diff outout
The developer who made the change has confirmed that he only modified 3 files. This is the output I get: c:\>svn diff --summarize -r 6:7 https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens M https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens/HMI_ERA_Tab1.c im M https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens/tp_ge_dp_objec ts.cim M https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens/HMI_Menu_Main. cim M https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens/HMI_ERA_Tab1.c im M https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens/tp_ge_dp_objec ts.cim M https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens/HMI_Menu_Main. cim -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Tuesday, October 30, 2012 11:40 AM To: Ahmed, Omair (GE Oil & Gas) Cc: users@subversion.apache.org Subject: Re: svn diff outout On Tue, Oct 30, 2012 at 12:25:59PM -0400, Ahmed, Omair (GE Oil & Gas) wrote: > This is command returns a double entry for each of the files which > changed between two versions. The Tortoise client displays a single > entry. > > c:\>svn diff --summarize -r 3:7 > https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens > https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens > > c:\temp\rel1.6.txt > > Do you know why that is happening? I don't know. It does not do that for me. This command, using a public URL, prints one changed file, which is correct: svn diff --summarize -c 1403696 https://svn.apache.org/repos/asf (-c 1403696 means the same as -r 1403695:1403696) Can you provide a reproduction recipe for your problem that I can try out on my own machine?
RESOLVED: svn diff outout
Yes, that was the problem; specifying a single URL gives me the correct/expected output. Thank you for your help! -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Tuesday, October 30, 2012 11:45 AM To: Ahmed, Omair (GE Oil & Gas); users@subversion.apache.org Subject: Re: svn diff outout On Tue, Oct 30, 2012 at 05:39:33PM +0100, Stefan Sperling wrote: > On Tue, Oct 30, 2012 at 12:25:59PM -0400, Ahmed, Omair (GE Oil & Gas) wrote: > > This is command returns a double entry for each of the files which > > changed between two versions. The Tortoise client displays a single > > entry. > > > > c:\>svn diff --summarize -r 3:7 > > https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens > > https://x.x.com/svn/muxbopcs_svn/trunk/GEMUX/LocalScreens > > > c:\temp\rel1.6.txt > > > > Do you know why that is happening? > > I don't know. It does not do that for me. > > This command, using a public URL, prints one changed file, which is correct: > svn diff --summarize -c 1403696 https://svn.apache.org/repos/asf > > (-c 1403696 means the same as -r 1403695:1403696) > > Can you provide a reproduction recipe for your problem that I can try > out on my own machine? Hmmm, looking closer, maybe the problem is simply that you passed the same URL twice? Each URL you specify is a diff target. So if you pass the same target twice you will see the same diff twice. As per the output of 'svn help diff', I am using this invocation: 1. diff [-c M | -r N[:M]] [TARGET[@REV]...] and *not* this one: 3. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV]
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
> I'm not quite sure if you really understand the impact of svn:ignore. > What behaviour are you expecting from the svn:ignore mechanism exactly, > and how would the expected behaviour impact your workflow? We want the unversioned files to not show in svn status or in tortoiseSVN's "Add" command when invoked on directories which contain unversioned files. I'll talk to other devs to see if there are other expected behaviors. > Based on past experience, I would guess that this is probably not as > simple as you imagine it to be, unfortunately. You are talking about > a major feature addition, not some small fix. > > Subversion has no concept of an unversioned property yet. > Such a concept would need to be added first which would require some design > and implementation effort. A lot of work would need to be done to make sure > this new kind of property interacts well with all other features of the > system (status, diff, commit, update, ...). That means writing a lot > regression tests to start with. > > This might turn out to be about as "simple" as the "file external" feature > turned out to be. A very simple idea on the surface but very hard to get > working correctly in all use cases, and we ended up frantically fixing a > lot of new bugs related to the feature over the course of several months. Alright, I got the picture. Don't worry, I'll look deeper into the matter and make a good effort to make things work nicely on our side before asking for such a feature. See below. > We do exactly the same thing in Subversion itself, and we do have > ignore patterns like *.c and so on within the bindings source directories. > There doesn't seem to be any problem with this in our project. > This command lists the patterns we use: >svn propget -v -R svn:ignore > https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings The problem is that the C files automatically generated for bindings are often mixed with standard versioned C files... However, after further inspection here, it seems to me that the binding files could indeed be put in a separate directory without requiring any code to be changed. My main concern is with the exported header files, but their names don't seem to vary much with the target platform and other compilation options in our system. Maybe I can tell Subversion to ignore the headers individually and also a special "bindings" directory containing the implementations. I'm going to investigate this further, maybe there is a way to adapt our system without requiring code changes after all. I'll report here soon.
RE: SVN Tag / Branch question
Bob, You are correct in making the statement below. However, what's confusing is that when I copied the Docs directory from /trunk to /tags/release-1.6, the directory included files from the previous release also. Basically, I was expecting to see just the new files. I am trying to understand how that happened and how to prevent. "Also, if you released your product from a certain svn revision, aren't ALL the files in that revision part of that release version?" -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Tuesday, October 30, 2012 11:36 AM To: Ahmed, Omair (GE Oil & Gas); users@subversion.apache.org Subject: RE: SVN Tag / Branch question > Hello, > > We did our first release in SVN today. I used the copy command (shown > below) to copy from /trunk to /tag. Since not everything in /trunk > was needed for this release, I had to specify the directories which were > needed. > > Q1. Is this the normal/correct way of doing things? For the new > release, just the Docs, MKVIE and Screens dirs. were needed. The others were > not. Not sure what you mean by "not needed". However, you don't save anything by not just copying trunk to tag. Since svn uses "cheap copies" copying the full trunk folder doesn't take any more space than copying certain folders. Also, if you released your product from a certain svn revision, aren't ALL the files in that revision part of that release version? > Our repo structure is as follows: > > C>svn list https://X.X.com/svn/muxbopcs_svn/trunk/MUX > > Control/ > Docs/ > MKVIE/ > Screens/ > sem_modbus/ > > Q2. Are we better off using release branches instead of copying to /tags? To svn a copy is a copy. tags and branches are semantic names. In general a tag isn't ever committed to. But, this is only by convention. > Q3. Sometime down the line, if I had to re-create a view of "Release > 1.6", do I just base my workspace on what's in /tags/release-1.6? Or > is there another/better way of re-creating a prior release? I would copy the tag to a branch and work from the branch. > Q4. I was also expecting /tags to contain just the new files for > Release 1.6. However, that wouldn't be case, right? I have a feeling > I am confusing myself over nothing. Basically, all a copy is, is a pointer to the location that it copied. So, the state of the path you copy to includes everything from the source path. But, once again, it is a cheap copy so no files are really copied. BOb
Re: SVN Tag / Branch question
On Tue, Oct 30, 2012 at 1:10 PM, Ahmed, Omair (GE Oil & Gas) wrote: > > However, what's confusing is that when I copied the Docs directory from > /trunk to /tags/release-1.6, the directory included files from the previous > release also. Basically, I was expecting to see just the new files. I am > trying to understand how that happened and how to prevent. You should get whatever is in the source of the copy (/trunk) at that revision. If there are files that no longer belong there in the current work, delete them. You'll still be able to recover them easily from the release tag that contained them and even (slightly less easily) by using peg-revision syntax to specify a revision where they existed. -- Les Mikesell lesmikes...@gmail.com
RE: SVN Tag / Branch question
> You are correct in making the statement below. > > However, what's confusing is that when I copied the Docs directory from /trunk > to /tags/release-1.6, the directory included files from the previous release > also. > Basically, I was expecting to see just the new files. I am trying to > understand > how that happened and how to prevent. I think perhaps you have a misunderstanding of how subversion revisions work. A revision contains ALL of the files in the path no matter what previous rev they were last changed in. Do you have different files in the same path that apply to different releases? If so, I think you are doing something wrong. For example, you should have... readme_v1.txt and then make a readme_v2.txt for a new release. You should just modify the readme.txt file accordingly and let svn keep track of which rev of that file goes with which release of your product. You should go and review Chapter 1 and 2 of the documentation. http://svnbook.red-bean.com/en/1.7/svn-book.html BOb > > "Also, if you released your product from a certain svn revision, aren't ALL > the > files in that revision part of that release version?" > > > -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Tuesday, October 30, 2012 11:36 AM > To: Ahmed, Omair (GE Oil & Gas); users@subversion.apache.org > Subject: RE: SVN Tag / Branch question > > > Hello, > > > > We did our first release in SVN today. I used the copy command (shown > > below) to copy from /trunk to /tag. Since not everything in /trunk > > was needed for this release, I had to specify the directories which were > needed. > > > > Q1. Is this the normal/correct way of doing things? For the new > > release, just the Docs, MKVIE and Screens dirs. were needed. The others were > not. > > Not sure what you mean by "not needed". However, you don't save anything by > not just copying trunk to tag. Since svn uses "cheap copies" copying the full > trunk folder doesn't take any more space than copying certain folders. Also, > if > you released your product from a certain svn revision, aren't ALL the files in > that revision part of that release version? > > > > Our repo structure is as follows: > > > > C>svn list https://X.X.com/svn/muxbopcs_svn/trunk/MUX > > > > Control/ > > Docs/ > > MKVIE/ > > Screens/ > > sem_modbus/ > > > > Q2. Are we better off using release branches instead of copying to /tags? > > To svn a copy is a copy. tags and branches are semantic names. In general a > tag isn't ever committed to. But, this is only by convention. > > > > Q3. Sometime down the line, if I had to re-create a view of "Release > > 1.6", do I just base my workspace on what's in /tags/release-1.6? Or > > is there another/better way of re-creating a prior release? > > I would copy the tag to a branch and work from the branch. > > > > Q4. I was also expecting /tags to contain just the new files for > > Release 1.6. However, that wouldn't be case, right? I have a feeling > > I am confusing myself over nothing. > > Basically, all a copy is, is a pointer to the location that it copied. So, > the state of > the path you copy to includes everything from the source path. But, once > again, > it is a cheap copy so no files are really copied. > > BOb > >
RE: SVN Tag / Branch question
> -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Tuesday, October 30, 2012 2:41 PM > To: Ahmed, Omair (GE Oil & Gas); users@subversion.apache.org > Subject: RE: SVN Tag / Branch question > > > You are correct in making the statement below. > > > > However, what's confusing is that when I copied the Docs directory > > from /trunk to /tags/release-1.6, the directory included files from the > previous release also. > > Basically, I was expecting to see just the new files. I am trying to > > understand how that happened and how to prevent. > > I think perhaps you have a misunderstanding of how subversion revisions work. > A revision contains ALL of the files in the path no matter what previous rev > they > were last changed in. Do you have different files in the same path that apply > to > different releases? If so, I think you are doing something wrong. > > For example, you should have... Sorry, the above should say: For example, you should NOT have... > > readme_v1.txt and then make a readme_v2.txt for a new release. You should > just modify the readme.txt file accordingly and let svn keep track of which > rev > of that file goes with which release of your product. > > You should go and review Chapter 1 and 2 of the documentation. > http://svnbook.red-bean.com/en/1.7/svn-book.html > > BOb > > > > > > > > "Also, if you released your product from a certain svn revision, > > aren't ALL the files in that revision part of that release version?" > > > > > > -Original Message- > > From: Bob Archer [mailto:bob.arc...@amsi.com] > > Sent: Tuesday, October 30, 2012 11:36 AM > > To: Ahmed, Omair (GE Oil & Gas); users@subversion.apache.org > > Subject: RE: SVN Tag / Branch question > > > > > Hello, > > > > > > We did our first release in SVN today. I used the copy command > > > (shown > > > below) to copy from /trunk to /tag. Since not everything in /trunk > > > was needed for this release, I had to specify the directories which > > > were > > needed. > > > > > > Q1. Is this the normal/correct way of doing things? For the new > > > release, just the Docs, MKVIE and Screens dirs. were needed. The > > > others were > > not. > > > > Not sure what you mean by "not needed". However, you don't save > > anything by not just copying trunk to tag. Since svn uses "cheap > > copies" copying the full trunk folder doesn't take any more space than > > copying certain folders. Also, if you released your product from a > > certain svn revision, aren't ALL the files in that revision part of that > > release > version? > > > > > > > Our repo structure is as follows: > > > > > > C>svn list https://X.X.com/svn/muxbopcs_svn/trunk/MUX > > > > > > Control/ > > > Docs/ > > > MKVIE/ > > > Screens/ > > > sem_modbus/ > > > > > > Q2. Are we better off using release branches instead of copying to /tags? > > > > To svn a copy is a copy. tags and branches are semantic names. In > > general a tag isn't ever committed to. But, this is only by convention. > > > > > > > Q3. Sometime down the line, if I had to re-create a view of "Release > > > 1.6", do I just base my workspace on what's in /tags/release-1.6? Or > > > is there another/better way of re-creating a prior release? > > > > I would copy the tag to a branch and work from the branch. > > > > > > > Q4. I was also expecting /tags to contain just the new files for > > > Release 1.6. However, that wouldn't be case, right? I have a > > > feeling I am confusing myself over nothing. > > > > Basically, all a copy is, is a pointer to the location that it copied. > > So, the state of the path you copy to includes everything from the > > source path. But, once again, it is a cheap copy so no files are really > > copied. > > > > BOb > > > >
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
On Tue, Oct 30, 2012 at 12:55 PM, Vitor Barata wrote: > > The problem is that the C files automatically generated for bindings > are often mixed with standard versioned C files... However, after > further inspection here, it seems to me that the binding files could > indeed be put in a separate directory without requiring any code to be > changed. If they are automatically generated, why not automatically delete them when finished with them? Or, you might look into using a distributed build automation like Jenkins so the builds would happen in a separate workspace and the cruft doesn't get in the way of developer commits. -- Les Mikesell lesmikes...@gmail.com
Re: [Bug] [Subversion 1.7] svn blame doesn't work for locally modified files
On Fri, Oct 14, 2011 at 6:49 AM, Daniel Shahaf wrote: > [ switching list, please drop users@ from further replies ] > > Konstantin Kolinko wrote on Fri, Oct 14, 2011 at 11:43:14 +0400: >> 2011/10/14 Andrey Paramonov : >> > On 13.10.2011 22:31, Ryan Schmidt wrote: >> >> >> >> On Oct 13, 2011, at 06:51, Andrey Paramonov wrote: >> >> >> > I believe Subversion can automagically translate line ending sequences >> > when transferring data to and from server. I use Windows, so I have >> > CRLF >> > sequences at the ends of the lines in my working copy. The question >> > is: what >> > is the EOL sequence on the server? >> >> >> >> >> >> On Oct 13, 2011, at 07:06, Andrey Paramonov wrote: >> >>> >> >>> On 13.10.2011 15:54, Daniel Shahaf wrote: >> >> What properties are set on your file? >> >>> >> >>> svn proplist returns nothing. >> >> >> >> If the svn:eol-style property is not set on the file, then Subversion does >> >> not modify the file in any way as it's stored in the repository. The EOL >> >> sequence (and every other byte in the file) is the same on the server as >> >> it >> >> is on the client. >> >> >> >> If, on the other hand, svn:eol-style is set to any valid value, then >> >> Subversion stores the file in the repository with LF line endings, and on >> >> checkout or export, the client translates the line endings to the style >> >> requested in the svn:eol-style property. >> >> >> > >> > By looking through the code in libsvn_client/blame.c I see that in >> > svn_client_blame5 working copy version of the file is unconditionally >> > normalized to have "\n" EOLs (by call to svn_subst_stream_translated). >> > However, it seems that svn_ra_get_file_revs2 doesn't do EOL normalization, >> > at least in my case (absent svn:eol-style). >> >> Confirming that the issue reproduces for me on Windows using a file >> that does not have svn:eol-style property. >> >> The svn blame filename@BASE, as mentioned earlier, works correctly, >> blaming unmodified base version of the file. >> >> >> If a file has svn:eol-style=native the issue does not reproduce >> and blame works correctly. >> >> > > @Both, thanks for the analysis. Could someone file a bug report and/or > send a patch, too? If you have a build environment, does the patch > below fix the problem? Hi All, Mike Pilato is tying off loose ends for the upcoming 1.8 release and asked me to check this patch for issue #4034 on my Windows machine. The patch doesn't appear to make any difference: With three files, with three different eols as per their names: trunk@1403813>svn st -v 99 pburba . 99 pburba file-with-CR-eols 99 pburba file-with-CRLF-eols 99 pburba file-with-LF-eols All three files have the same contents but for eols: trunk@1403813>type file-with-CRLF-eols A B C D E F Blame works fine with no local mods as expected: trunk@1403813>svn blame file-with-CR-eols 9 pburba A 9 pburba B 9 pburba C 9 pburba D 9 pburba E 9 pburba F trunk@1403813>svn blame file-with-CRLF-eols 9 pburba A 9 pburba B 9 pburba C 9 pburba D 9 pburba E 9 pburba F trunk@1403813>svn blame file-with-LF-eols 9 pburba A 9 pburba B 9 pburba C 9 pburba D 9 pburba E 9 pburba F I edited line #3 in each file like this: trunk@1403813>svn diff file-with-CRLF-eols Index: file-with-CRLF-eols === --- file-with-CRLF-eols (revision 9) +++ file-with-CRLF-eols (working copy) @@ -1,6 +1,6 @@ A B -C +C-mod D E F Without Daniels patch we see the bug described previously in the thread: trunk@1403813>svn blame file-with-CR-eols - - A - - B - - C-mod - - D - - E - - F trunk@1403813>svn blame file-with-CRLF-eols - - A - - B - - C-mod - - D - - E - - F trunk@1403813>svn blame file-with-LF-eols 9 pburba A 9 pburba B - - C-mod 9 pburba D 9 pburba E 9 pburba F But with Daniel's patch I see no difference in the blame output: trunk@1403813>svn blame file-with-CR-eols - - A - - B - - C-mod - - D - - E - - F trunk@1403813>svn blame file-with-CRLF-eols - - A - - B - - C-mod - - D - - E - - F trunk@1403813>svn blame file-with-LF-eols 9 pburba A 9 pburba B - - C-mod 9 pburba D 9 pburba E 9 pburba F -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Develo
svn log output in directory-trees that contain moved sub-trees
Hello, I have some trouble wit the logic of the 'svn log' command. When reorganizing the directory structure in a repository by using 'svn move' I don't get the desired output from 'svn log' in all circumstances. I think this is best demonstrated by this sample script: --- svnadmin create /tmp/repo svn co file:///tmp/repo /tmp/wc cd /tmp/wc svn mkdir --parents ./old/place echo "some content" >old/place/foobar svn add ./old/place/foobar svn ci . -m "initial commit" svn mkdir --parents ./new/place svn ci . -m "new structure" svn move old/place new/place/old svn ci . -m "migration" # update directory revisions svn up echo -e "\n here I see revision r1, containing 'foobar'\n" svn log -v echo -e "\n here again I see revision r1\n" svn log -v new/place/old echo -e "\n here no revision r1 is present\n" svn log -v new --- What I expected was to see all the history about what happened in the "old/place" directory anywhere in the "new" sub-tree. But this is not the case. Can somebody explain to me why this is the case? I produced this using subversion 1.6.17. Best regards, Matthias -- Matthias Gerstner, Dipl.-Wirtsch.-Inf. (FH) Entwicklung NCP engineering GmbH Dombühler Straße 2, D-90449, Nürnberg Geschäftsführer Peter Söll, HRB-Nr: 77 86 Nürnberg E-Mail: matthias.gerst...@ncp-e.com Internet: http://www.ncp-e.com pgp7WWeIZhbWK.pgp Description: PGP signature
Re: svn log output in directory-trees that contain moved sub-trees
Matthias Gerstner wrote on Tue, Oct 30, 2012 at 17:21:39 +0100: > echo -e "\n here no revision r1 is present\n" > svn log -v new "new" was created in r2 so running 'log' on it will not show earlier revisions. (Well, unless you pass -g) 'log' just walks the history of a node; it won't show revisions in which that node did not exist. But the reference to r1 is not lost; is it present in line 4 of the output: [[[ r3 | danielsh | 2012-10-31 04:41:25 + (Wed, 31 Oct 2012) | 1 line Changed paths: A /new/place/old (from /old/place:1) D /old/place ... ]]] HTH Daniel > --- > > What I expected was to see all the history about what happened in the > "old/place" directory anywhere in the "new" sub-tree. But this is not > the case. > > Can somebody explain to me why this is the case? > > I produced this using subversion 1.6.17. > > Best regards, > > Matthias > > -- > > Matthias Gerstner, Dipl.-Wirtsch.-Inf. (FH) > Entwicklung > > NCP engineering GmbH > Dombühler Straße 2, D-90449, Nürnberg > Geschäftsführer Peter Söll, HRB-Nr: 77 86 Nürnberg > > E-Mail: matthias.gerst...@ncp-e.com > Internet: http://www.ncp-e.com
