You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by John Maher <Jo...@rotair.com> on 2013/08/09 19:27:28 UTC
Strange behavior
Hello
I'm getting some very strange behavior from subversion. One of the biggest issues is why does it not ignore files I tell it to ignore? Can someone tell me how to get it to ignore files and directories properly? Following the documentation does not work. I have the following setup:
Coins
Coins/Cents
Coins/Nickels
Coins/Dimes
Coins/Quarters
And on each of those directories I have the following value for the svn:ignore property (results of svn propget svn:ignore:)
*.suo
*.user
obj
bin
I have created a branch called LGcents. I try to merge back into trunk and this is what I get:
--- Merging r14 through r50 into '.':
G Dimes\Dimes.suo
Skipped 'Dimes\obj'
Skipped 'Coins.suo'
Skipped 'bin'
Skipped missing target: 'Dimes\bin'
Skipped 'obj'
G Dimes
C Build.bat
Skipped missing target: 'Quarters\bin'
Skipped 'Quarters\obj'
Skipped 'Quarters\Quarters.suo'
G Quarters
U Nickels\Nickels.Designer.vb
Skipped missing target: 'Nickels\bin'
Skipped 'Nickels\obj'
Skipped 'Nickels\Nickels.suo'
G Nickels
C Cents\Cents.suo
Skipped missing target: 'Cents\bin'
Skipped 'Cents\obj'
G Cents
G .
--- Recording mergeinfo for merge of r14 through r50 into '.':
U .
Summary of conflicts:
Tree conflicts: 2
Skipped paths: 13
And svn status returns this:
C Build.bat
> local add, incoming add upon merge
M Cents\Censt.Designer.vb
M Cents\Censt.vb
D C Cents\Cents.suo
> local delete, incoming delete upon merge
! C Cents\bin
> local delete, incoming delete upon merge
M Dimes\Dimes.Designer.vb
M Dimes\Dimes.suo
M Dimes\Dimes.vb
! C Dimes\bin
> local delete, incoming delete upon merge
! C Nickels\bin
> local delete, incoming delete upon merge
M Quarters\Quarters.Designer.vb
M Quarters\Quarters.vb
! C Quarters\bin
> local delete, incoming delete upon merge
Summary of conflicts:
Tree conflicts: 6
Why does merge report 2 conflicts and status report 6? That is very confusing.
Why is build.bat causing a local add and incoming add? That file has been added many revisions ago.
Why is Cents.suo causing a local delete. That file was not deleted either. Nor were any of the other conflicts.
Both the trunk and branch were committed and updated in that order. Then I switch the directory between the branch and trunk since it is set up with the auxillery files needed to run the project.
The first merge I tried failed and after that I issued the ignore commands and also issued the resolve command a lot.
Is subversion extremely fragile? Is there a way to fix it? Is there any more complete documentation? The book is incomplete.
Thanks
JM
Re: Strange behavior
Posted by Ullrich Jans <ul...@elektrobit.com>.
Am 09.08.2013 21:58, schrieb Edwin Castro:
> On 8/9/13 10:27 AM, John Maher wrote:
>> And svn status returns this:
>> C Build.bat
>> > local add, incoming add upon merge
>
> You svn add Build.bat in trunk. Later you svn add Build.bat in your
> branch. Subversion sees those as separate objects with individual history.
I've seen this here, too. It seems to be related to a user creating a
branch with the OS tools without telling SVN about it, then adding it to
SVN, then porting over changes by hand, then trying to merge in more
changes...
To create a branch, I've learned to always do an svn copy between URLs,
e.g. svn cp file:///repository/trunk file:///repository/branches/mybranch.
Cheers,
Ulli
--
Ullrich Jans, Specialist, IT-A
Phone: +49 9131 7701-6627, mailto:ullrich.jans@elektrobit.com
Fax: +49 9131 7701-6333, www.elektrobit.com
Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany
Managing Directors: Alexander Kocher, Gregor Zink
Register Court Fürth HRB 4886
----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.
Re: Strange behavior
Posted by Edwin Castro <0p...@gmx.us>.
On 8/9/13 10:27 AM, John Maher wrote:
> And svn status returns this:
> C Build.bat
> > local add, incoming add upon merge
You svn add Build.bat in trunk. Later you svn add Build.bat in your
branch. Subversion sees those as separate objects with individual history.
If you had svn add Build.bat in the trunk, then merged to the branch
(without svn add Build.bat in the branch), then you'd have the same
object with history that has diverged. In this scenario you can make
changes in the trunk and in the branch (history for the one object
diverges) and later merge the changes between the branches (synchronize
the diverging histories).
So to recap, in your current scenario you have two objects each with one
history. In the correct scenario you have one object with two related
histories.
The svn book details how to deal with a scenario like this. You have to
svn delete Build.bat in the branch (but keep the changes somewhere),
commit, then merge from trunk (might need to use the --force argument, I
forget) putting Build.bat from trunk in your branch, then manually merge
the changes from the old Build.bat and the new Build.bat. Once you fix
this you should never need to perform this process again.
The conflicts reporting "local delete, incoming delete upon merge" occur
due to a similar reason.
--
Edwin G. Castro
RE: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
Thanks Johan, I'll have to try it.
-----Original Message-----
From: Johan Corveleyn [mailto:jcorvel@gmail.com]
Sent: Tuesday, August 13, 2013 11:42 AM
To: John Maher
Cc: Ryan Schmidt; Subversion Users
Subject: Re: Strange behavior
On Tue, Aug 13, 2013 at 4:12 PM, John Maher <Jo...@rotair.com> wrote:
> Thanks Ryan. I learned a lot from your reply. Namely the global-ignores are really local global-ignores and I have to copy the config file over to anyone who may import.
>
As of version 1.8 (for the svn client), there is a new feature called "Repository Dictated Configuration" [1], which you can use to set a global-ignores that will be applied by all standard 1.8 clients. It works by setting an svn:global-ignores property on a directory in your repository, which then applies to the entire subtree under that directory.
However, I'm not sure if that feature applies to 'svn import' (because it doesn't have a working copy). I guess someone will have to try it :-).
[1] http://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config
--
Johan
Re: Strange behavior
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Aug 13, 2013 at 4:12 PM, John Maher <Jo...@rotair.com> wrote:
> Thanks Ryan. I learned a lot from your reply. Namely the global-ignores are really local global-ignores and I have to copy the config file over to anyone who may import.
>
As of version 1.8 (for the svn client), there is a new feature called
"Repository Dictated Configuration" [1], which you can use to set a
global-ignores that will be applied by all standard 1.8 clients. It
works by setting an svn:global-ignores property on a directory in your
repository, which then applies to the entire subtree under that
directory.
However, I'm not sure if that feature applies to 'svn import' (because
it doesn't have a working copy). I guess someone will have to try it
:-).
[1] http://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config
--
Johan
RE: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
Thanks Ryan. I learned a lot from your reply. Namely the global-ignores are really local global-ignores and I have to copy the config file over to anyone who may import. I also appreciate your description of the in-place import. I like the idea of being able to un-add a file. That allows you to experiment with wildcards without fear of damaging the repository. Adding a file to the repository that you do not wish can be considered damaging if it guarantees a merge conflict every time.
Thanks again
JM
-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2012c@ryandesign.com]
Sent: Monday, August 12, 2013 5:25 PM
To: John Maher
Cc: Subversion Users
Subject: Re: Strange behavior
On Aug 12, 2013, at 09:17, John Maher wrote:
> Thanks for your help, but I still do not know how to get this to work. Perhaps I should give a little background. The project that I mentioned in my original post was a test project created just to learn how to get subversion to work. The production code that I wish to put in one repository resides in 62 directories that have over 2000 files in them of which only some of them can be included otherwise merging becomes impossible. The whole point of this exercise is to get merging to work since it causes unnecessary difficultly to try to separate new features with bug fixes in a single branch. But this is all I could get to work. Unfortunately no matter how much I read (I read the first half of the book twice) and how much I checkout and commit the tool fails to work for me.
I'll let others address your merging questions, since I read the book before Subversion 1.5 was released, when merge tracking was introduced, which has simplified merging considerably.
> And the only reason I have been complaining about the documentation is hoping to point out areas where it is very unclear and misleading. Anyone who knows how to use the tool will never catch on to the poorly written areas of the documentation, they are biased. You NEED someone who doesn't know how to use the tool to indicate areas that need to be addressed.
I totally agree, and please continue doing this. I did originally learn Subversion by reading the book, so that was the basis for my praise of it, but I have learned many more things by reading years of messages on this list so sometimes it's hard for me to recall where a particular bit of knowledge came from.
> Now the two suggestions I have are auto properties and in place import. The links provided do not relate to my situation.
I think when I said auto-props, I meant global-ignores. Sorry about that. They're related in that they're both considered when importing. I think I see why I said that: you wrote:
> Does import work with the ignore property? It mentions it in the help, but I do not know if the help is wrong. If properties need to be applied to a working directory how do I use them with the import command BEFORE a working copy exists?
I was confusing the svn:ignore property with the global-ignores config file setting. The svn:ignore property is applied to a directory so that files inside it might be ignored (and which affects all users who might check out a working copy of this directory), and yes, that has to happen in a working copy. The global-ignores setting in your Subversion config file has a similar function but affects all working copies and import actions you perform, regardless what server is involved, and affects only you.
> The provided link indicates properties that get set DURING the import. I need to ignore files BEFORE the import. Like I originally stated, I need to import SOME files. Importing compiler generated files OR user settings causes problem and makes merging impossible thereby defeating some of the benefits of using subversion. If this method will solve this problem can you provide me with a link indicating how to do this? I can not find anything in the book nor the provided link. If you could give me some keywords to search for that would help also. I tried searching and all I find is questions relating to different actions.
>
> I looked at the import command in the book and with the svn help command and could not see how to use the svn:ignore. The import-in-place command works on a single file. That would indicate I would need to issue the command hundreds of times. Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files.
The in-place import does not operate on a single file; it is a procedure for importing any number of items within a directory. The example in the FAQ showed how to do an in-place import of four files in /etc. I'll try to explain in more detail.
Let's say you have a directory of original files, and a repository you want to import them into. You want to import some files but not others. Maybe you want to set properties on some files, such as MIME types or line ending styles.
== Normal Import ==
With a normal import, you run a single command "svn import" and the contents of the directory are imported into the repository. While doing so, Subversion considers your global-ignores (to decide which files not to import) and your auto-props (to decide what properties to apply to files that are imported), but there is no opportunity to inspect the results of that consideration before the files are committed to the repository.
Once a normal import is completed, your original directory is untouched. To get a working copy that you can perform additional Subversion operations in, you have to check it out from the repository, and then usually delete your original directory. But if there are any files in the original directory that you did not import, but that you still want to have in the new working copy, you have to manually move them over.
If what got imported wasn't what you wanted, you have to clean it up later in the working copy -- "svn rm" files you didn't mean to import; "svn add" files you wanted to import but forgot; "svn mv" files around -- or "svn rm" the entire imported directory and try again, or maybe even delete the whole repository and start over if that's what you want (and it might be, if you imported huge files that you didn't need, since "svn rm" won't recover the space they used, or confidential files, since otherwise they'll forever be in the history).
In my opinion, "svn import" is ok for importing small collections of files, where you want to import everything (or are sure your global-ignores cover every file you don't want to import) and don't care about properties (or are sure your auto-props cover every situation). For larger or more complicated imports, I choose the in-place import method.
== In-Place Import ==
Instead of "svn import", I often prefer and in-place import. In this method, you first "svn mkdir" an empty directory in the repository where your files will go. Then you "svn co" this directory on top of your directory of original files, thereby transforming it into a working copy with unversioned files. You can then "svn add" files you want to import. If you add a file you didn't want (perhaps by running "svn add *") you can "svn revert" the file to essentially "un-add" it. You can "svn ps" to set additional properties. (Perhaps you want to set "svn:ignore" on some directories.) You haven't committed anything yet, except for the creation of the empty directory. You can continue to modify your pending commit as desired, using "svn st" as often as you like to inspect what will be committed, and finally "svn ci" when ready to commit it.
And as noted, your original directory of files has *become* the working copy, which is often what people want anyway.
The FAQ entry on in-place import is pretty limited, I concede. I assume that since it is a FAQ entry it is not in the book. I would like to see the in-place import method described in greater detail, in the book, replacing the FAQ entry.
Re: Strange behavior
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 12, 2013, at 09:17, John Maher wrote:
> Thanks for your help, but I still do not know how to get this to work. Perhaps I should give a little background. The project that I mentioned in my original post was a test project created just to learn how to get subversion to work. The production code that I wish to put in one repository resides in 62 directories that have over 2000 files in them of which only some of them can be included otherwise merging becomes impossible. The whole point of this exercise is to get merging to work since it causes unnecessary difficultly to try to separate new features with bug fixes in a single branch. But this is all I could get to work. Unfortunately no matter how much I read (I read the first half of the book twice) and how much I checkout and commit the tool fails to work for me.
I'll let others address your merging questions, since I read the book before Subversion 1.5 was released, when merge tracking was introduced, which has simplified merging considerably.
> And the only reason I have been complaining about the documentation is hoping to point out areas where it is very unclear and misleading. Anyone who knows how to use the tool will never catch on to the poorly written areas of the documentation, they are biased. You NEED someone who doesn't know how to use the tool to indicate areas that need to be addressed.
I totally agree, and please continue doing this. I did originally learn Subversion by reading the book, so that was the basis for my praise of it, but I have learned many more things by reading years of messages on this list so sometimes it's hard for me to recall where a particular bit of knowledge came from.
> Now the two suggestions I have are auto properties and in place import. The links provided do not relate to my situation.
I think when I said auto-props, I meant global-ignores. Sorry about that. They're related in that they're both considered when importing. I think I see why I said that: you wrote:
> Does import work with the ignore property? It mentions it in the help, but I do not know if the help is wrong. If properties need to be applied to a working directory how do I use them with the import command BEFORE a working copy exists?
I was confusing the svn:ignore property with the global-ignores config file setting. The svn:ignore property is applied to a directory so that files inside it might be ignored (and which affects all users who might check out a working copy of this directory), and yes, that has to happen in a working copy. The global-ignores setting in your Subversion config file has a similar function but affects all working copies and import actions you perform, regardless what server is involved, and affects only you.
> The provided link indicates properties that get set DURING the import. I need to ignore files BEFORE the import. Like I originally stated, I need to import SOME files. Importing compiler generated files OR user settings causes problem and makes merging impossible thereby defeating some of the benefits of using subversion. If this method will solve this problem can you provide me with a link indicating how to do this? I can not find anything in the book nor the provided link. If you could give me some keywords to search for that would help also. I tried searching and all I find is questions relating to different actions.
>
> I looked at the import command in the book and with the svn help command and could not see how to use the svn:ignore. The import-in-place command works on a single file. That would indicate I would need to issue the command hundreds of times. Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files.
The in-place import does not operate on a single file; it is a procedure for importing any number of items within a directory. The example in the FAQ showed how to do an in-place import of four files in /etc. I'll try to explain in more detail.
Let's say you have a directory of original files, and a repository you want to import them into. You want to import some files but not others. Maybe you want to set properties on some files, such as MIME types or line ending styles.
== Normal Import ==
With a normal import, you run a single command "svn import" and the contents of the directory are imported into the repository. While doing so, Subversion considers your global-ignores (to decide which files not to import) and your auto-props (to decide what properties to apply to files that are imported), but there is no opportunity to inspect the results of that consideration before the files are committed to the repository.
Once a normal import is completed, your original directory is untouched. To get a working copy that you can perform additional Subversion operations in, you have to check it out from the repository, and then usually delete your original directory. But if there are any files in the original directory that you did not import, but that you still want to have in the new working copy, you have to manually move them over.
If what got imported wasn't what you wanted, you have to clean it up later in the working copy -- "svn rm" files you didn't mean to import; "svn add" files you wanted to import but forgot; "svn mv" files around -- or "svn rm" the entire imported directory and try again, or maybe even delete the whole repository and start over if that's what you want (and it might be, if you imported huge files that you didn't need, since "svn rm" won't recover the space they used, or confidential files, since otherwise they'll forever be in the history).
In my opinion, "svn import" is ok for importing small collections of files, where you want to import everything (or are sure your global-ignores cover every file you don't want to import) and don't care about properties (or are sure your auto-props cover every situation). For larger or more complicated imports, I choose the in-place import method.
== In-Place Import ==
Instead of "svn import", I often prefer and in-place import. In this method, you first "svn mkdir" an empty directory in the repository where your files will go. Then you "svn co" this directory on top of your directory of original files, thereby transforming it into a working copy with unversioned files. You can then "svn add" files you want to import. If you add a file you didn't want (perhaps by running "svn add *") you can "svn revert" the file to essentially "un-add" it. You can "svn ps" to set additional properties. (Perhaps you want to set "svn:ignore" on some directories.) You haven't committed anything yet, except for the creation of the empty directory. You can continue to modify your pending commit as desired, using "svn st" as often as you like to inspect what will be committed, and finally "svn ci" when ready to commit it.
And as noted, your original directory of files has *become* the working copy, which is often what people want anyway.
The FAQ entry on in-place import is pretty limited, I concede. I assume that since it is a FAQ entry it is not in the book. I would like to see the in-place import method described in greater detail, in the book, replacing the FAQ entry.
Re: Strange behavior
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag John Maher,
am Dienstag, 13. August 2013 um 15:39 schrieben Sie:
> Follow the book on how it instructs to import a project then
> it becomes impossible to merge and branch.
Branching is always possible and always equally cheap regardless of
what you did before, because it breaks down to a cheap copy operation
with preserving history. The only thing which may cost time is
updating/checking the new branch out.
If you have merge problems because of your tests or whatever one
solution may be just recording merge info. This way you can move and
copy and delete things in any way you like and make subversion think
that those changes are already applied to a selected directory without
really applying them, meaning you won't get any merge conflicts now or
later from the revisions you recorded as already merged. This may
prevent re-creating your repo and losing history.
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@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: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
Thanks Andrew, I started going through your steps and discovered something.
My repository is called either iERP85_v2 or iERP85_V2. Visual SVN reports the latter but the former works with the client. Don't know which nor why one product chooses one over the other. My mistake was assuming I make a mistake with the repository. The mistake I actually made was trusting visual svn server. Although svn did report the smaller v it can be difficult to notice.
So I created two branches for two new features I am working on. I'll see how they go.
Thanks again
JM
-----Original Message-----
From: Andrew Reedick [mailto:Andrew.Reedick@cbeyond.net]
Sent: Tuesday, August 13, 2013 10:27 AM
To: John Maher; users@subversion.apache.org
Subject: RE: Strange behavior
> -----Original Message-----
> From: John Maher [mailto:JohnM@rotair.com]
> Sent: Tuesday, August 13, 2013 9:40 AM
> To: Thorsten Schöning; users@subversion.apache.org
> Subject: RE: Strange behavior
>
> Hi Thorsten
>
> A good response to a less than good post. People could take lessons
> from you.
>
> Actually, its been a frustrating week. Sometimes subversion accepts
> the wrong slash in a path, other times it does not. Sometimes it
> enforces case sensitivity in a url other times it does not.
Sounds like normal windows-unix interaction issues. They're not that bad if you have experience with UNIX systems. In the Windows CMD shell, if you wrap your pathnames in double quotes, you can use forward slashes instead of backslashes for directory separators, e.g. dir /s "c:/program files/subversion", which helps when feeding paths between CMD commands and svn commands.
> Follow the
> book on how it instructs to import a project then it becomes
> impossible to merge and branch.
That's odd. Very odd. It's much more likely that you're not grokking some paradigm or missed a step when creating the branch. You might want to post your branch/merge test process (especially the commands) and have the list vet it.
> And now for the second time I must discard my repository along with
> all the history I've accumulated. Yes you can say frustrating,
> bordering on maddening.
Why? If you have a good initial import checked in, then create a new test branch, or even roll trunk back to the initial import. Example:
Revision 10 of /trunk is your "200 commands" to import the initial baseline.
1. Create a new test branch from rev 10: svn copy svn://server/trunk svn://server/branches/new_test_branch@10
Or if you want to roll trunk back to rev 10:
1. svn rm svn://server/trunk
2. svn copy svn://server/trunk@10 svn://server/trunk 3. create new test branch: svn copy svn://server/trunk svn://server/branches/new_test_branch
The original trunk branch (with revisions 11+) is still available via peg revisions, but peg revisions are a topic for later.
Or if you really want a fresh repo, then you can use 'svn export -r' to export the initial working baseline and then import those files into your new test repository. Meaning, if revision 10 represents your initial "200 commands" of importing files, then export revision 10 using 'svn export -r 10 ...'. This lets you start a new repo without having to re-do the import from scratch. I would tell you about 'svnadmin dump', but given your current mental state, that's probably not a good idea.
>
> I got a good laugh from:
> "Of course it can, just copy your 200 commands line by line one after
> another into a batch file."
I know it was a humorous comment, but...
Anyway, dealing with new software with new paradigms/assumptions can be very frustrating (e.g. going from ClearCase to 1.3 SVN, *grrrr*) but you need to take a step back and relax. Importing and branching and merging in svn 1.8 really isn't (shouldn't be) that difficult. Plus, svn 1.8 is pretty robust and a mature product, so you shouldn't be fighting with it that much.
Good luck, and keep up the perseverance. "That which doesn't kill you, probably leaves you crippled and weak" (or something to that effect.)
RE: Strange behavior
Posted by Andrew Reedick <An...@cbeyond.net>.
> -----Original Message-----
> From: John Maher [mailto:JohnM@rotair.com]
> Sent: Tuesday, August 13, 2013 9:40 AM
> To: Thorsten Schöning; users@subversion.apache.org
> Subject: RE: Strange behavior
>
> Hi Thorsten
>
> A good response to a less than good post. People could take lessons
> from you.
>
> Actually, its been a frustrating week. Sometimes subversion accepts
> the wrong slash in a path, other times it does not. Sometimes it
> enforces case sensitivity in a url other times it does not.
Sounds like normal windows-unix interaction issues. They're not that bad if you have experience with UNIX systems. In the Windows CMD shell, if you wrap your pathnames in double quotes, you can use forward slashes instead of backslashes for directory separators, e.g. dir /s "c:/program files/subversion", which helps when feeding paths between CMD commands and svn commands.
> Follow the
> book on how it instructs to import a project then it becomes impossible
> to merge and branch.
That's odd. Very odd. It's much more likely that you're not grokking some paradigm or missed a step when creating the branch. You might want to post your branch/merge test process (especially the commands) and have the list vet it.
> And now for the second time I must discard my
> repository along with all the history I've accumulated. Yes you can
> say frustrating, bordering on maddening.
Why? If you have a good initial import checked in, then create a new test branch, or even roll trunk back to the initial import. Example:
Revision 10 of /trunk is your "200 commands" to import the initial baseline.
1. Create a new test branch from rev 10: svn copy svn://server/trunk svn://server/branches/new_test_branch@10
Or if you want to roll trunk back to rev 10:
1. svn rm svn://server/trunk
2. svn copy svn://server/trunk@10 svn://server/trunk
3. create new test branch: svn copy svn://server/trunk svn://server/branches/new_test_branch
The original trunk branch (with revisions 11+) is still available via peg revisions, but peg revisions are a topic for later.
Or if you really want a fresh repo, then you can use 'svn export -r' to export the initial working baseline and then import those files into your new test repository. Meaning, if revision 10 represents your initial "200 commands" of importing files, then export revision 10 using 'svn export -r 10 ...'. This lets you start a new repo without having to re-do the import from scratch. I would tell you about 'svnadmin dump', but given your current mental state, that's probably not a good idea.
>
> I got a good laugh from:
> "Of course it can, just copy your 200 commands line by line one after
> another into a batch file."
I know it was a humorous comment, but...
Anyway, dealing with new software with new paradigms/assumptions can be very frustrating (e.g. going from ClearCase to 1.3 SVN, *grrrr*) but you need to take a step back and relax. Importing and branching and merging in svn 1.8 really isn't (shouldn't be) that difficult. Plus, svn 1.8 is pretty robust and a mature product, so you shouldn't be fighting with it that much.
Good luck, and keep up the perseverance. "That which doesn't kill you, probably leaves you crippled and weak" (or something to that effect.)
RE: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
Hi Thorsten
A good response to a less than good post. People could take lessons from you.
Actually, its been a frustrating week. Sometimes subversion accepts the wrong slash in a path, other times it does not. Sometimes it enforces case sensitivity in a url other times it does not. Follow the book on how it instructs to import a project then it becomes impossible to merge and branch. And now for the second time I must discard my repository along with all the history I've accumulated. Yes you can say frustrating, bordering on maddening.
I got a good laugh from:
"Of course it can, just copy your 200 commands line by line one after another into a batch file."
JM
-----Original Message-----
From: Thorsten Schöning [mailto:tschoening@am-soft.de]
Sent: Monday, August 12, 2013 4:43 PM
To: users@subversion.apache.org
Subject: Re: Strange behavior
Guten Tag John Maher,
am Montag, 12. August 2013 um 20:57 schrieben Sie:
> Otherwise there are
> over 200 manual operations required just to create a repository.
As you mentioned you are still working on Windows XP, you are aware of TortoiseSVN, aren't you? There shouldn't be the need to run any command yourself as Tortoise is able to create repos and act as a subversion client.
> The way some people praise subversion I would think this can be
> automated.
Of course it can, just copy your 200 commands line by line one after another into a batch file. ;-)
> But then again perhaps those are the people who use subversion for the
> simplest of builds.
Frustrating day, wasn't it? :-)
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@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: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
One thing I forgot to mention is that yes, I know of Tortoise. I started with that. It works good for the most commonly used stuff, but falls short as a complete solution. So I really need to know how the "real" tool works. That is why I am struggling with the command line.
JM
-----Original Message-----
From: Thorsten Schöning [mailto:tschoening@am-soft.de]
Sent: Monday, August 12, 2013 4:43 PM
To: users@subversion.apache.org
Subject: Re: Strange behavior
Guten Tag John Maher,
am Montag, 12. August 2013 um 20:57 schrieben Sie:
> Otherwise there are
> over 200 manual operations required just to create a repository.
As you mentioned you are still working on Windows XP, you are aware of TortoiseSVN, aren't you? There shouldn't be the need to run any command yourself as Tortoise is able to create repos and act as a subversion client.
> The way some people praise subversion I would think this can be
> automated.
Of course it can, just copy your 200 commands line by line one after another into a batch file. ;-)
> But then again perhaps those are the people who use subversion for the
> simplest of builds.
Frustrating day, wasn't it? :-)
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@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: Strange behavior
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag John Maher,
am Montag, 12. August 2013 um 20:57 schrieben Sie:
> Otherwise there are
> over 200 manual operations required just to create a repository.
As you mentioned you are still working on Windows XP, you are aware of
TortoiseSVN, aren't you? There shouldn't be the need to run any
command yourself as Tortoise is able to create repos and act as a
subversion client.
> The way some people praise subversion I would think this can be
> automated.
Of course it can, just copy your 200 commands line by line one after
another into a batch file. ;-)
> But then again perhaps those are the people who use
> subversion for the simplest of builds.
Frustrating day, wasn't it? :-)
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@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: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
Thanks Bob. You have been very helpful. I didn't know that there was an html version of the book. I've been using the pdf version and haven't found a way to search that. The global ignores worked. Now I'm on to my third repository. I hate having to lose all the history I'm accumulated, but that's how it goes.
Thanks again.
JM
-----Original Message-----
From: Bob Archer [mailto:Bob.Archer@amsi.com]
Sent: Monday, August 12, 2013 3:33 PM
To: John Maher; Edwin Castro; users@subversion.apache.org
Subject: RE: Strange behavior
> Thanks Bob, that may be exactly what I am looking for. Something that
> would affect all the files without having to issue over 200 commands
> or build a dummy directory just for importing. Although that second
> suggestion provided by Andrew is definitely better than the first.
>
> I couldn't find where it discusses the global config in the book, if it does at all.
> And even if it does I doubt it would help because it won't tell me
> where to find the file. Unless there is a command to edit it. I
> tried a search and someone says there is a site-wide config (what I
> need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file.
>
> I can't even find the name of it. If someone can provide that I could
> at least search for it and hope it has some clue inside as how to alter it.
>
Search for "global-ignores" in the single page version of the redbook: http://svnbook.red-bean.com/en/1.7/svn-book.html
Here's infor about runtime configuration: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.confarea
BOb
> JM
>
> -----Original Message-----
> From: Bob Archer [mailto:Bob.Archer@amsi.com]
> Sent: Monday, August 12, 2013 3:02 PM
> To: John Maher; Edwin Castro; users@subversion.apache.org
> Subject: RE: Strange behavior
>
> > Thanks Edwin,
> >
> > That's exactly what I am trying to do. I was looking for a way for
> > the tool to accomplish this. I'd be just as glad if someone tells
> > me it is impossible, which I suspect it may be. Otherwise there are
> > over
> > 200 manual operations required just to create a repository. The way
> > some people praise subversion I would think this can be automated.
> > But then again perhaps those are the people who use subversion for
> > the
> simplest of builds.
>
> I'm not sure what you are asking for? An automated way to ignore files
> you don't want check in? Or are you talking about import?
>
> I believe import respects global ignores if you have them set up in
> your config file.
>
> BOb
>
>
> >
> > JM
> >
> > -----Original Message-----
> > From: Edwin Castro [mailto:0ptikGhost@gmx.us]
> > Sent: Monday, August 12, 2013 11:55 AM
> > To: users@subversion.apache.org
> > Subject: Re: Strange behavior
> >
> > On 8/12/13 6:17 AM, John Maher wrote:
> > > Are you sure this is the only way? It would seem odd that this
> > > toll does not
> > provide a way to import an enterprise level application without
> > ignoring the compiler generated files.
> >
> > In cases like this I perform a "clean" operation that removes
> > compiler generated files. I would also remove any user specific
> > files as by definition they should not be part of the repository.
> >
> > --
> > Edwin
> >
>
>
RE: Strange behavior
Posted by Bob Archer <Bo...@amsi.com>.
> Thanks Bob, that may be exactly what I am looking for. Something that would
> affect all the files without having to issue over 200 commands or build a
> dummy directory just for importing. Although that second suggestion provided
> by Andrew is definitely better than the first.
>
> I couldn't find where it discusses the global config in the book, if it does at all.
> And even if it does I doubt it would help because it won't tell me where to find
> the file. Unless there is a command to edit it. I tried a search and someone
> says there is a site-wide config (what I need) and a user config but not where
> they are. I am using Windows XP and an having a difficult time finding this file.
>
> I can't even find the name of it. If someone can provide that I could at least
> search for it and hope it has some clue inside as how to alter it.
>
Search for "global-ignores" in the single page version of the redbook: http://svnbook.red-bean.com/en/1.7/svn-book.html
Here's infor about runtime configuration: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.confarea
BOb
> JM
>
> -----Original Message-----
> From: Bob Archer [mailto:Bob.Archer@amsi.com]
> Sent: Monday, August 12, 2013 3:02 PM
> To: John Maher; Edwin Castro; users@subversion.apache.org
> Subject: RE: Strange behavior
>
> > Thanks Edwin,
> >
> > That's exactly what I am trying to do. I was looking for a way for
> > the tool to accomplish this. I'd be just as glad if someone tells me
> > it is impossible, which I suspect it may be. Otherwise there are over
> > 200 manual operations required just to create a repository. The way
> > some people praise subversion I would think this can be automated.
> > But then again perhaps those are the people who use subversion for the
> simplest of builds.
>
> I'm not sure what you are asking for? An automated way to ignore files you
> don't want check in? Or are you talking about import?
>
> I believe import respects global ignores if you have them set up in your config
> file.
>
> BOb
>
>
> >
> > JM
> >
> > -----Original Message-----
> > From: Edwin Castro [mailto:0ptikGhost@gmx.us]
> > Sent: Monday, August 12, 2013 11:55 AM
> > To: users@subversion.apache.org
> > Subject: Re: Strange behavior
> >
> > On 8/12/13 6:17 AM, John Maher wrote:
> > > Are you sure this is the only way? It would seem odd that this toll
> > > does not
> > provide a way to import an enterprise level application without
> > ignoring the compiler generated files.
> >
> > In cases like this I perform a "clean" operation that removes compiler
> > generated files. I would also remove any user specific files as by
> > definition they should not be part of the repository.
> >
> > --
> > Edwin
> >
>
>
RE: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
An excellent alternative. I will keep this in mind.
Thanks Andrew
JM
-----Original Message-----
From: Andrew Reedick [mailto:Andrew.Reedick@cbeyond.net]
Sent: Monday, August 12, 2013 3:52 PM
To: John Maher; users@subversion.apache.org
Subject: RE: Strange behavior
> -----Original Message-----
> From: John Maher [mailto:JohnM@rotair.com]
> Sent: Monday, August 12, 2013 3:27 PM
> To: Bob Archer; Edwin Castro; users@subversion.apache.org
> Subject: RE: Strange behavior
>
> Thanks Bob, that may be exactly what I am looking for. Something that
> would affect all the files without having to issue over 200 commands
> or build a dummy directory just for importing. Although that second
> suggestion provided by Andrew is definitely better than the first.
>
> I couldn't find where it discusses the global config in the book, if
> it does at all. And even if it does I doubt it would help because it
> won't tell me where to find the file. Unless there is a command to
> edit it. I tried a search and someone says there is a site-wide
> config (what I need) and a user config but not where they are. I am
> using Windows XP and an having a difficult time finding this file.
>
> I can't even find the name of it. If someone can provide that I could
> at least search for it and hope it has some clue inside as how to
> alter it.
>
Plan B might be to use svn_load_dirs.pl: http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
It has a "glob_ignores" option, or will try to read your global-ignores from your local svn config file.
>From the script:
===============
# If no glob_ignores specified, try to deduce from config file, # or use the default below.
my $ignores_str =
'*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store';
if ( defined $opt_glob_ignores)
{
$ignores_str = $opt_glob_ignores;
}
elsif ( -f "$ENV{HOME}/.subversion/config" )
{
open my $conf, "$ENV{HOME}/.subversion/config";
while (<$conf>)
{
if ( /^global-ignores\s*=\s*(.*?)\s*$/ )
{
$ignores_str = $1;
last;
}
}
}
Re: Strange behavior
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 12, 2013, at 14:52, Andrew Reedick wrote:
> Plan B might be to use svn_load_dirs.pl: http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
>
> It has a "glob_ignores" option, or will try to read your global-ignores from your local svn config file.
>
> From the script:
> ===============
> # If no glob_ignores specified, try to deduce from config file,
> # or use the default below.
> my $ignores_str =
> '*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store';
>
> if ( defined $opt_glob_ignores)
> {
> $ignores_str = $opt_glob_ignores;
> }
> elsif ( -f "$ENV{HOME}/.subversion/config" )
> {
> open my $conf, "$ENV{HOME}/.subversion/config";
> while (<$conf>)
> {
> if ( /^global-ignores\s*=\s*(.*?)\s*$/ )
> {
> $ignores_str = $1;
> last;
> }
> }
> }
svn_load_dirs is for loading multiple versions of an old project into a version control system for the first time. The user hasn't said anything about wanting to do that so I don't think there's any need to jump to svn_load_dirs. It seems like its glob_ignores just does what the built-in global-ignores already does.
RE: Strange behavior
Posted by Andrew Reedick <An...@cbeyond.net>.
> -----Original Message-----
> From: John Maher [mailto:JohnM@rotair.com]
> Sent: Monday, August 12, 2013 3:27 PM
> To: Bob Archer; Edwin Castro; users@subversion.apache.org
> Subject: RE: Strange behavior
>
> Thanks Bob, that may be exactly what I am looking for. Something that
> would affect all the files without having to issue over 200 commands or
> build a dummy directory just for importing. Although that second
> suggestion provided by Andrew is definitely better than the first.
>
> I couldn't find where it discusses the global config in the book, if it
> does at all. And even if it does I doubt it would help because it
> won't tell me where to find the file. Unless there is a command to
> edit it. I tried a search and someone says there is a site-wide config
> (what I need) and a user config but not where they are. I am using
> Windows XP and an having a difficult time finding this file.
>
> I can't even find the name of it. If someone can provide that I could
> at least search for it and hope it has some clue inside as how to alter
> it.
>
Plan B might be to use svn_load_dirs.pl: http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
It has a "glob_ignores" option, or will try to read your global-ignores from your local svn config file.
>From the script:
===============
# If no glob_ignores specified, try to deduce from config file,
# or use the default below.
my $ignores_str =
'*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store';
if ( defined $opt_glob_ignores)
{
$ignores_str = $opt_glob_ignores;
}
elsif ( -f "$ENV{HOME}/.subversion/config" )
{
open my $conf, "$ENV{HOME}/.subversion/config";
while (<$conf>)
{
if ( /^global-ignores\s*=\s*(.*?)\s*$/ )
{
$ignores_str = $1;
last;
}
}
}
RE: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
Thanks David. For the past week and a half I've been wrestling with this thing. Searching, reading, trying, back to searching. Time to switch gears but I needed to get over this hurdle. I'm now on the second repository I have to dispose of (and all the history with it) so I hope the 3rd time's the charm.
Thanks again
JM
-----Original Message-----
From: David Chapman [mailto:dcchapman@acm.org]
Sent: Monday, August 12, 2013 3:49 PM
To: John Maher
Cc: users@subversion.apache.org
Subject: Re: Strange behavior
On 8/12/2013 12:27 PM, John Maher wrote:
> Thanks Bob, that may be exactly what I am looking for. Something that would affect all the files without having to issue over 200 commands or build a dummy directory just for importing. Although that second suggestion provided by Andrew is definitely better than the first.
>
> I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file.
>
> I can't even find the name of it. If someone can provide that I could at least search for it and hope it has some clue inside as how to alter it.
>
>
First link from Google (search was "windows xp subversion configuration file location",
http://stackoverflow.com/questions/6310539/where-is-the-subversion-global-config-file-for-the-slik-svn-client-for-windows)
sez:
C:\Documents and Settings\%USERNAME%\Application Data\Subversion\config
I no longer run on Windows XP, so I don't remember if this is the proper place for the file, but I have no reason to doubt it.
For Windows 7 it's in:
C:\Users\%USERNAME%\AppData\Roaming\Subversion\config
Which I can confirm.
In the "config" file, I have my global-ignores for Windows set to:
global-ignores = *.obj *.lib *.map *.exe *.bak *.pdb *.ilk *.idb
There might need to be a few more; it's been several years since I have imported existing code into my Subversion repositories. But you get the idea.
--
David Chapman dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
Re: Strange behavior
Posted by David Chapman <dc...@acm.org>.
On 8/12/2013 12:27 PM, John Maher wrote:
> Thanks Bob, that may be exactly what I am looking for. Something that would affect all the files without having to issue over 200 commands or build a dummy directory just for importing. Although that second suggestion provided by Andrew is definitely better than the first.
>
> I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file.
>
> I can't even find the name of it. If someone can provide that I could at least search for it and hope it has some clue inside as how to alter it.
>
>
First link from Google (search was "windows xp subversion configuration
file location",
http://stackoverflow.com/questions/6310539/where-is-the-subversion-global-config-file-for-the-slik-svn-client-for-windows)
sez:
C:\Documents and Settings\%USERNAME%\Application Data\Subversion\config
I no longer run on Windows XP, so I don't remember if this is the proper
place for the file, but I have no reason to doubt it.
For Windows 7 it's in:
C:\Users\%USERNAME%\AppData\Roaming\Subversion\config
Which I can confirm.
In the "config" file, I have my global-ignores for Windows set to:
global-ignores = *.obj *.lib *.map *.exe *.bak *.pdb *.ilk *.idb
There might need to be a few more; it's been several years since I have
imported existing code into my Subversion repositories. But you get the
idea.
--
David Chapman dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
RE: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
Thanks Mark, that's an excellent shortcut.
JM
-----Original Message-----
From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Monday, August 12, 2013 4:05 PM
To: John Maher
Cc: Bob Archer; Edwin Castro; users@subversion.apache.org
Subject: Re: Strange behavior
On Mon, Aug 12, 2013 at 3:27 PM, John Maher <Jo...@rotair.com> wrote:
> I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file.
>
The configuration area is in the book in here:
http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html
The footnote links to the easiest way to find the file:
%APPDATA%\Subversion
Just enter that into the Windows Run dialog or the address bar of the file explorer and it will take you to the right folder where the configuration files are found. This is true for XP as well as Win 7.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Strange behavior
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Aug 12, 2013 at 3:27 PM, John Maher <Jo...@rotair.com> wrote:
> I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file.
>
The configuration area is in the book in here:
http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html
The footnote links to the easiest way to find the file:
%APPDATA%\Subversion
Just enter that into the Windows Run dialog or the address bar of the
file explorer and it will take you to the right folder where the
configuration files are found. This is true for XP as well as Win 7.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
Thanks Bob, that may be exactly what I am looking for. Something that would affect all the files without having to issue over 200 commands or build a dummy directory just for importing. Although that second suggestion provided by Andrew is definitely better than the first.
I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file.
I can't even find the name of it. If someone can provide that I could at least search for it and hope it has some clue inside as how to alter it.
JM
-----Original Message-----
From: Bob Archer [mailto:Bob.Archer@amsi.com]
Sent: Monday, August 12, 2013 3:02 PM
To: John Maher; Edwin Castro; users@subversion.apache.org
Subject: RE: Strange behavior
> Thanks Edwin,
>
> That's exactly what I am trying to do. I was looking for a way for
> the tool to accomplish this. I'd be just as glad if someone tells me
> it is impossible, which I suspect it may be. Otherwise there are over
> 200 manual operations required just to create a repository. The way
> some people praise subversion I would think this can be automated.
> But then again perhaps those are the people who use subversion for the simplest of builds.
I'm not sure what you are asking for? An automated way to ignore files you don't want check in? Or are you talking about import?
I believe import respects global ignores if you have them set up in your config file.
BOb
>
> JM
>
> -----Original Message-----
> From: Edwin Castro [mailto:0ptikGhost@gmx.us]
> Sent: Monday, August 12, 2013 11:55 AM
> To: users@subversion.apache.org
> Subject: Re: Strange behavior
>
> On 8/12/13 6:17 AM, John Maher wrote:
> > Are you sure this is the only way? It would seem odd that this toll
> > does not
> provide a way to import an enterprise level application without
> ignoring the compiler generated files.
>
> In cases like this I perform a "clean" operation that removes compiler
> generated files. I would also remove any user specific files as by
> definition they should not be part of the repository.
>
> --
> Edwin
>
RE: Strange behavior
Posted by Bob Archer <Bo...@amsi.com>.
> Thanks Edwin,
>
> That's exactly what I am trying to do. I was looking for a way for the tool to
> accomplish this. I'd be just as glad if someone tells me it is impossible, which I
> suspect it may be. Otherwise there are over 200 manual operations required
> just to create a repository. The way some people praise subversion I would
> think this can be automated. But then again perhaps those are the people who
> use subversion for the simplest of builds.
I'm not sure what you are asking for? An automated way to ignore files you don't want check in? Or are you talking about import?
I believe import respects global ignores if you have them set up in your config file.
BOb
>
> JM
>
> -----Original Message-----
> From: Edwin Castro [mailto:0ptikGhost@gmx.us]
> Sent: Monday, August 12, 2013 11:55 AM
> To: users@subversion.apache.org
> Subject: Re: Strange behavior
>
> On 8/12/13 6:17 AM, John Maher wrote:
> > Are you sure this is the only way? It would seem odd that this toll does not
> provide a way to import an enterprise level application without ignoring the
> compiler generated files.
>
> In cases like this I perform a "clean" operation that removes compiler
> generated files. I would also remove any user specific files as by definition they
> should not be part of the repository.
>
> --
> Edwin
>
Re: Strange behavior
Posted by Edwin Castro <0p...@gmx.us>.
On 8/12/13 10:57 AM, John Maher wrote:
> But then again perhaps those are the people who use subversion for the simplest of builds.
At my previous employer I was partly responsible for a codebase in
subversion whose trunk was 2+ GB large. The codebase included over 1400
C#, C++, SQL, and WiX projects. I think many of us have very complicated
builds. We simply choose to use the correct tool for the job. Working on
Windows I wrote many PowerShell scripts to help me manage bulk operations.
I have no evidence but I suspect most of us have lots of experience
working with very large codebases in subversion. Suggesting that we have
the "simplest of builds" comes across as elitist which is odd coming
from an obvious beginner. There is clear evidence that there's a
cognitive mismatch between your current understanding and how subversion
is intended to be used. We're here to help you but that help will come
these discussions occur with respect. Sometimes it is better to present
the experts with the problem you are trying to solve including how
you've attempted to solve it, accepting the possibility that your
current approach may not be the best approach. Seems like I keep hearing
"you're doing it wrong" from the list and you keep responding with "I
don't care, how do accomplish this anyway." I don't think that's a good
attitude to take.
--
Edwin
RE: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
Thanks Edwin,
That's exactly what I am trying to do. I was looking for a way for the tool to accomplish this. I'd be just as glad if someone tells me it is impossible, which I suspect it may be. Otherwise there are over 200 manual operations required just to create a repository. The way some people praise subversion I would think this can be automated. But then again perhaps those are the people who use subversion for the simplest of builds.
JM
-----Original Message-----
From: Edwin Castro [mailto:0ptikGhost@gmx.us]
Sent: Monday, August 12, 2013 11:55 AM
To: users@subversion.apache.org
Subject: Re: Strange behavior
On 8/12/13 6:17 AM, John Maher wrote:
> Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files.
In cases like this I perform a "clean" operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository.
--
Edwin
Re: Strange behavior
Posted by Edwin Castro <0p...@gmx.us>.
On 8/12/13 6:17 AM, John Maher wrote:
> Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files.
In cases like this I perform a "clean" operation that removes compiler
generated files. I would also remove any user specific files as by
definition they should not be part of the repository.
--
Edwin
RE: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
I apologize. It was wrong to say " no one here is interested . . ." Some people are uninterested. Some are interested. Some are extremely helpful. Some can be very egotistical. Just like the real world, you get a mix of good and less than good.
I should've never responded like that to a group because of an apple that I did not agree with. Being frustrated with this product (no excuse) add to that critisim when I try to help (maybe small excuse there) equals my reason, though it is not a good one.
There's inconsistencies with the svn help command also. Maybe in the future I'll help with the documentation. But when you get a free product, and want to give back then take flak when you think you are helping it kinda kills the urge to help.
But I never should've used an absolute like that. Thank you for pointing it out Johan and pointing it out in a polite way instead of condescending.
-----Original Message-----
From: Johan Corveleyn [mailto:jcorvel@gmail.com]
Sent: Monday, August 12, 2013 3:54 PM
To: John Maher
Cc: Ryan Schmidt; Subversion Users
Subject: Re: Strange behavior
On Mon, Aug 12, 2013 at 4:17 PM, John Maher <Jo...@rotair.com> wrote:
...
> And the only reason I have been complaining about the documentation is hoping to point out areas where it is very unclear and misleading. Anyone who knows how to use the tool will never catch on to the poorly written areas of the documentation, they are biased. You NEED someone who doesn't know how to use the tool to indicate areas that need to be addressed. But since no one here is interested to maintaining good documentation and are more interested in hunting out any obscured word they can find just to say "look, it is right!!" it seems best if I never, ever point out any flaws in the documentation. I will just selfishly concern myself with my own problems, it seems all will get along better that way.
>
"But since no one here is interested to maintaining good documentation ..."? Oh come on. Of course we want good documentation, and feedback to help improve it is more than welcome. But give the people on this list some credit too, please.
Have you read the very first response you got, from Ryan Schmidt, pointing you to the website of the book, where your feedback would be most welcome?
Also, please keep in mind that the most useful feedback comes in the form of concrete suggestions, or pointing out specific shortcomings.
If you say "I didn't find anything about X", and someone replies "it's on page Y", then the feedback loop is closed. If you want your "not finding about X" to be any further useful book feedback, you'll have to argue why your non-finding is a book problem (rather than an "oops, I looked at the wrong section" problem), and that it should be explained or pointed to on page Z, or wherever you expected to find info about it.
--
Johan
Re: Strange behavior
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Aug 12, 2013 at 4:17 PM, John Maher <Jo...@rotair.com> wrote:
...
> And the only reason I have been complaining about the documentation is hoping to point out areas where it is very unclear and misleading. Anyone who knows how to use the tool will never catch on to the poorly written areas of the documentation, they are biased. You NEED someone who doesn't know how to use the tool to indicate areas that need to be addressed. But since no one here is interested to maintaining good documentation and are more interested in hunting out any obscured word they can find just to say "look, it is right!!" it seems best if I never, ever point out any flaws in the documentation. I will just selfishly concern myself with my own problems, it seems all will get along better that way.
>
"But since no one here is interested to maintaining good documentation
..."? Oh come on. Of course we want good documentation, and feedback
to help improve it is more than welcome. But give the people on this
list some credit too, please.
Have you read the very first response you got, from Ryan Schmidt,
pointing you to the website of the book, where your feedback would be
most welcome?
Also, please keep in mind that the most useful feedback comes in the
form of concrete suggestions, or pointing out specific shortcomings.
If you say "I didn't find anything about X", and someone replies "it's
on page Y", then the feedback loop is closed. If you want your "not
finding about X" to be any further useful book feedback, you'll have
to argue why your non-finding is a book problem (rather than an "oops,
I looked at the wrong section" problem), and that it should be
explained or pointed to on page Z, or wherever you expected to find
info about it.
--
Johan
RE: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
Thanks for the quick merge lesson. I would need to use the same directory for the branch as the trunk since there is a rather large infrastructure required to run the project (It is an ERP application). So I would plan on using switch. As long there are no hidden gotchas I should be OK.
-----Original Message-----
From: Andrew Reedick [mailto:Andrew.Reedick@cbeyond.net]
Sent: Monday, August 12, 2013 1:39 PM
To: John Maher
Cc: Subversion Users
Subject: RE: Strange behavior
> -----Original Message-----
> From: John Maher [mailto:JohnM@rotair.com]
> Sent: Monday, August 12, 2013 10:18 AM
> To: Ryan Schmidt
> Cc: Subversion Users
> Subject: RE: Strange behavior
>
> Thanks for your help, but I still do not know how to get this to work.
> Perhaps I should give a little background. The project that I
> mentioned in my original post was a test project created just to learn
> how to get subversion to work. The production code that I wish to put
> in one repository resides in 62 directories that have over 2000 files
> in them of which only some of them can be included otherwise merging
> becomes impossible. The whole point of this exercise is to get
> merging to work since it causes unnecessary difficultly to try to
> separate new features with bug fixes in a single branch. But this is
> all I could get to work. Unfortunately no matter how much I read (I
> read the first half of the book twice) and how much I checkout and
> commit the tool fails to work for me.
You're overthinking this. You can use OS level commands to trim down the files to import. Copy the files to a temp directory, delete the files you don't want imported, and then run 'svn import' on the tmp dir. Even if you have mistakes in the import, you can use 'svn rm' and 'svn add' to clean things up.
It would be nice if you could pass 'svn import' a list of filenames/regexes to include or exclude, but modern shells already have the tools to filter and delete files, so there's little need to add those wheels to 'svn import'. Especially since the import is normally a one-time event.
Are you using 'svn import' multiple times? (Such as to create additional branches of the code?) If so, that would be bad, as in wrong paradigm/workflow.
As for branching, here's the short version for the 1.8 svn client:
0) Use 'svn import' to create the initial baseline, say /trunk.
then
1) Create the branch: 'svn copy svn:/server/trunk svn:/server/branches/foo.2.0.0'
2) Create branch workspace: cd /myworkspaces && svn co svn:/server/branches/foo.2.0.0' && cd foo.2.0.0
3) Work on foo.2.0.0
3.1) 'svn add' to add new files (svn:ignore will help here.)
3.2) 'svn ci' to commit the files
3.2) Periodically merge trunk changes up to foo.2.0.0: svn merge ^/trunk
Note: makes sure your foo.2.0.0 changes are checked in before merging up from trunk, 'svn status'
When foo.2.0.0 is "done", first merge trunk up to foo.2.0.0 to make sure that foo.2.0.0 has the current trunk changes
4) 'svn merge ^/trunk'
4.1) Resolve any conflicts.
Now merge foo.2.0.0 down to trunk.
5) Create a clean merge workspace
cd /myworkspaces && 'svn co svn:/server/trunk' && cd trunk
Note: if you are reusing a workspace, then 'svn status' and 'svn update' to make sure it's clean and ready for a merge.
6) 'svn merge ^/branches/foo.2.0.0'
6.1) Resolve any conflicts.
7) 'svn ci'
RE: Strange behavior
Posted by Andrew Reedick <An...@cbeyond.net>.
> -----Original Message-----
> From: John Maher [mailto:JohnM@rotair.com]
> Sent: Monday, August 12, 2013 10:18 AM
> To: Ryan Schmidt
> Cc: Subversion Users
> Subject: RE: Strange behavior
>
> Thanks for your help, but I still do not know how to get this to work.
> Perhaps I should give a little background. The project that I
> mentioned in my original post was a test project created just to learn
> how to get subversion to work. The production code that I wish to put
> in one repository resides in 62 directories that have over 2000 files
> in them of which only some of them can be included otherwise merging
> becomes impossible. The whole point of this exercise is to get merging
> to work since it causes unnecessary difficultly to try to separate new
> features with bug fixes in a single branch. But this is all I could
> get to work. Unfortunately no matter how much I read (I read the first
> half of the book twice) and how much I checkout and commit the tool
> fails to work for me.
You're overthinking this. You can use OS level commands to trim down the files to import. Copy the files to a temp directory, delete the files you don't want imported, and then run 'svn import' on the tmp dir. Even if you have mistakes in the import, you can use 'svn rm' and 'svn add' to clean things up.
It would be nice if you could pass 'svn import' a list of filenames/regexes to include or exclude, but modern shells already have the tools to filter and delete files, so there's little need to add those wheels to 'svn import'. Especially since the import is normally a one-time event.
Are you using 'svn import' multiple times? (Such as to create additional branches of the code?) If so, that would be bad, as in wrong paradigm/workflow.
As for branching, here's the short version for the 1.8 svn client:
0) Use 'svn import' to create the initial baseline, say /trunk.
then
1) Create the branch: 'svn copy svn:/server/trunk svn:/server/branches/foo.2.0.0'
2) Create branch workspace: cd /myworkspaces && svn co svn:/server/branches/foo.2.0.0' && cd foo.2.0.0
3) Work on foo.2.0.0
3.1) 'svn add' to add new files (svn:ignore will help here.)
3.2) 'svn ci' to commit the files
3.2) Periodically merge trunk changes up to foo.2.0.0: svn merge ^/trunk
Note: makes sure your foo.2.0.0 changes are checked in before merging up from trunk, 'svn status'
When foo.2.0.0 is "done", first merge trunk up to foo.2.0.0 to make sure that foo.2.0.0 has the current trunk changes
4) 'svn merge ^/trunk'
4.1) Resolve any conflicts.
Now merge foo.2.0.0 down to trunk.
5) Create a clean merge workspace
cd /myworkspaces && 'svn co svn:/server/trunk' && cd trunk
Note: if you are reusing a workspace, then 'svn status' and 'svn update' to make sure it's clean and ready for a merge.
6) 'svn merge ^/branches/foo.2.0.0'
6.1) Resolve any conflicts.
7) 'svn ci'
RE: Strange behavior
Posted by John Maher <Jo...@rotair.com>.
Thanks for your help, but I still do not know how to get this to work. Perhaps I should give a little background. The project that I mentioned in my original post was a test project created just to learn how to get subversion to work. The production code that I wish to put in one repository resides in 62 directories that have over 2000 files in them of which only some of them can be included otherwise merging becomes impossible. The whole point of this exercise is to get merging to work since it causes unnecessary difficultly to try to separate new features with bug fixes in a single branch. But this is all I could get to work. Unfortunately no matter how much I read (I read the first half of the book twice) and how much I checkout and commit the tool fails to work for me.
And the only reason I have been complaining about the documentation is hoping to point out areas where it is very unclear and misleading. Anyone who knows how to use the tool will never catch on to the poorly written areas of the documentation, they are biased. You NEED someone who doesn't know how to use the tool to indicate areas that need to be addressed. But since no one here is interested to maintaining good documentation and are more interested in hunting out any obscured word they can find just to say "look, it is right!!" it seems best if I never, ever point out any flaws in the documentation. I will just selfishly concern myself with my own problems, it seems all will get along better that way.
Now the two suggestions I have are auto properties and in place import. The links provided do not relate to my situation.
The provided link indicates properties that get set DURING the import. I need to ignore files BEFORE the import. Like I originally stated, I need to import SOME files. Importing compiler generated files OR user settings causes problem and makes merging impossible thereby defeating some of the benefits of using subversion. If this method will solve this problem can you provide me with a link indicating how to do this? I can not find anything in the book nor the provided link. If you could give me some keywords to search for that would help also. I tried searching and all I find is questions relating to different actions.
I looked at the import command in the book and with the svn help command and could not see how to use the svn:ignore. The import-in-place command works on a single file. That would indicate I would need to issue the command hundreds of times. Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files.
JM
-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2012c@ryandesign.com]
Sent: Friday, August 09, 2013 4:17 PM
To: John Maher
Cc: Subversion Users
Subject: Re: Strange behavior
Remember to Reply All so that your message goes to the mailing list too, not just to me.
On Aug 9, 2013, at 14:59, John Maher wrote:
> Thanks for your reply. I appreciate informing me that subversion is robust. I was concerned it was getting corrupted by the strange behavior. Plus you've also helped by telling me that the ignore property does not mean ignore, it means sometimes ignore. On page 68 of the book it explains that the ignore property is used to eliminate files from svn status. But your explanation matches my observations, thank you. The book is wrong again.
>
> I tried to delete the files from the repository with svn delete, but that failed because they were not part of the current revision. So it seems that I have to delete the repository and create it again (for the 3rd time).
>
> Does import work with the ignore property? It mentions it in the help, but I do not know if the help is wrong. If properties need to be applied to a working directory how do I use them with the import command BEFORE a working copy exists?. I followed the instructions in the book, created a repository and it came out all wrong, again.
>
> Can someone tell me how to get code files into the repository and stop the compiler generated files and directories?
>
> Thanks
> JM
Page 68 of the PDF version of the book is within the section "Ignoring Unversioned Items", but the items you're talking about are versioned, not unversioned.
"svn import" will obey your svn autoprops:
http://svnbook.red-bean.com/en/1.7/svn.advanced.props.html#svn.advanced.props.auto
But I often prefer to avoid the "svn import" command and do an "in-place import" instead:
http://subversion.apache.org/faq.html#in-place-import
This affords you the opportunity to be more selective about what you import and to add properties before committing.
Re: Strange behavior
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Ryan Schmidt,
am Freitag, 9. August 2013 um 22:16 schrieben Sie:
>> I tried to delete the files from the repository with svn delete,
>> but that failed because they were not part of the current revision.
>> So it seems that I have to delete the repository and create it
>> again (for the 3rd time).
No you don't, just update your working copy to HEAD and delete the
files. This of course will work if your are on HEAD and the files are
still there and not already deleted before. There's even no problem
with deleting files in different directories within your working copy
in the same commit.
Besides that, you should really stop complaining about wrong
documentation just because you are frustrated with getting things
done, if it seems that you simply misunderstood important parts if it.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@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: Strange behavior
Posted by Ryan Schmidt <su...@ryandesign.com>.
Remember to Reply All so that your message goes to the mailing list too, not just to me.
On Aug 9, 2013, at 14:59, John Maher wrote:
> Thanks for your reply. I appreciate informing me that subversion is robust. I was concerned it was getting corrupted by the strange behavior. Plus you've also helped by telling me that the ignore property does not mean ignore, it means sometimes ignore. On page 68 of the book it explains that the ignore property is used to eliminate files from svn status. But your explanation matches my observations, thank you. The book is wrong again.
>
> I tried to delete the files from the repository with svn delete, but that failed because they were not part of the current revision. So it seems that I have to delete the repository and create it again (for the 3rd time).
>
> Does import work with the ignore property? It mentions it in the help, but I do not know if the help is wrong. If properties need to be applied to a working directory how do I use them with the import command BEFORE a working copy exists?. I followed the instructions in the book, created a repository and it came out all wrong, again.
>
> Can someone tell me how to get code files into the repository and stop the compiler generated files and directories?
>
> Thanks
> JM
Page 68 of the PDF version of the book is within the section "Ignoring Unversioned Items", but the items you're talking about are versioned, not unversioned.
"svn import" will obey your svn autoprops:
http://svnbook.red-bean.com/en/1.7/svn.advanced.props.html#svn.advanced.props.auto
But I often prefer to avoid the "svn import" command and do an "in-place import" instead:
http://subversion.apache.org/faq.html#in-place-import
This affords you the opportunity to be more selective about what you import and to add properties before committing.
Re: Strange behavior
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 9, 2013, at 12:27, John Maher wrote:
> One of the biggest issues is why does it not ignore files I tell it to ignore?
The patterns you specify in svn:ignore properties are only so that Subversion does not suggest those files to be added to the repository.
For example, if you run "svn status" and it tells you some files are unversioned (status "?"), but you never intend to version them, then you add those files to svn:ignore so that Subversion won't tell you about them anymore.
But if you've already added the files to your repository, as seems to be the case here, then svn:ignore is no longer applicable.
> Is subversion extremely fragile? Is there a way to fix it?
I would call Subversion extremely robust.
> Is there any more complete documentation? The book is incomplete.
The book is undoubtedly incomplete, as most documents are, however I have found the Subversion Book to be among the best open-source documentation efforts of any project I've worked with. The book is maintained by a separate group, and if you have specific feedback for them, see the "Feedback/Contributing" heading on their web site:
http://svnbook.org/