subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Maher <Jo...@rotair.com>
Subject RE: Strange behavior
Date Tue, 13 Aug 2013 14:12:30 GMT
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.






Mime
View raw message