> Following up my previous post about improved file rename support to
> make vendor tree imports easier, how to you all feel about the
> concept of allowing tortoise to import a directory tree over the top
> of an existing working copy?
> I,e, deleting any files that are not in the imported tree, adding any
> new files, and allowing some sort of options to deal with renamed
I don't think that "import" would be the correct command here.
May I suggest that this gets implemented with a right-drag operation?
* get the source-tarball of the vendor tree
* extract the vendor tree
* select the vendor tree
* right-drag the vendor tree to the correct working copy location
Then, TSVN would show up a dialog, then start comparing those two
directory trees and the files in it. When the scanning is complete, show
the 'result' in a list control like this:
dst file status
Then, ask the user if (s)he wants to apply those changes to the working
copy. If yes, execute the corresponding commands (add/delete).
After that, the user can commit those changes.
I have no idea how you even want to find out if a file has been renamed
in a vendor tree - usually that's nowhere documented, you just get a new
version of the library.
> If others feel this idea has merit, I would be willing to have a go
> at implementing it. (I have VS2005 and don't mind getting my hands
> dirty, but have never looked looked at the tortoise source before so
> your (or my) mileage may vary.)
Would be great if you could send in a patch for this!
Some pointers to get you started:
* you don't need to implement the right-drag handler, I'll do that as
soon as you got the TortoiseProc command
* to add a TortoiseProc command, you need to add it to the TSVNCommand
enum, and below that to the commandInfo array. Then just add an "if
(command == cmdYourNewCommand)" and put your code in there. You should
maybe add a new class and files for handling those vendor trees.
* I would first check the status of the vendor tree in the working copy
to make sure it doesn't contain local modifications. If it has, then
copying the new files over the working copy files would overwrite those
> Notes: 1. Obviously I haven't worked out all the details, I'm mainly
> trolling for a ideas.
That's what this mailing list is for: discussing how to implement a
> 2, Even without gui changes a tortoiseproc
> option to do what I'm suggesting would be better than the batch files
> I use atm.
It really needs to have an UI. Users don't like commands that just do
something and don't tell exactly what they're doing or what they've done.
> 3. For bonus points I would also like to see the
> equivalent functionality for the svn copies.
Not sure what you mean by 'svn copies'. Can you explain?
> I maintain a C++ library
> where the headers used to compile the libs need to be commited as
> part of the distribution. The distribution directory is then svn
> copied into projects that use the library. How do other users handle
You mean like we do with the berkeley db's? We just have the header
files in the same vendor tree folder.
> P.S. I can't remember who made the comment about Leica in reply to a
> previous post but no I'm not based in Herrbrugg. Leica have a few
> international R&D offices these days, if you're ever in Brisbane let
> me know.
That was me :)
I'm not sure that I will ever be in that area, but I had to ask because
Heerbrugg is just 10 minutes away from where I live.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Jun 21 20:05:50 2006