> Yes, it is a bit long winded. There is another way, which is a bit easier.
> 1. Create a new directory in repo browser to hold your project
> 2. Checkout this empty folder onto your PC
> 3. Move/copy your existing project into this folder
> 4. Add the project files/subfolders to subversion
> 5. Commit
> It is not much easier, but it saves one set of network traffic because
> you just do Add instead of Import/Checkout.
> You can save such a list to a text file and just paste it into the
> properties page.
Yep, true, but that does not reduce the steps required. I was thinking
of Import+svn:externals in one step to reduce the steps needed from
8/5 to 1 :)
> Where would you apply those ignore properties? To the top folder or to
> every folder recursively?
Thinking of the same think as properties are now: checkbox
> What if different folders need different ignore lists (a common
> requirement)? Where are you going to set the externals? Maybe *you*
> always set them in the same place, but others may not.
Sure, it is a common requirement, if you have a project for example
that consists of Windows part and some handheld part, it'll be written
in different IDEs and therefore - have different excludes.
However I'm not speaking of this as a requirement, but as a feature to
reduce the time required for a new user or when importing projects to
the svn. In the situation above one way is to add the handheld part
and the windows part in 2 imports, each with the proper excludes set.
But I completely understand that there will be cases that this feature
will not apply... fine... it can always be done as it is now...
I have come to that idea looking at mine projects and some other
colleagues - obviously the common case is to have project-development
environment-excludes related, so making it easy for the common case (even
if there is only 1 edit box and checkbox in the Import UI, and the
user to make the lists in notepad) will be of a great help.
> Also, there are some developments going on in Subversion (search the svn
> list for "svn takeover") which may help with this. If we do something
> now, it may be redundant when SVN 1.3 comes out, so I think we should
> wait a bit to see what is coming.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Aug 26 14:15:22 2005