Matt.Sullivan@leica-geosystems.com wrote:
>> 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
>> file1 modified
>> file2 new
>> file3 removed
>>
>> Then, ask the user if (s)he wants to apply those changes to the working
>> copy. If yes, execute the corresponding commands (add/delete).
>
> I hadn't considered comparing the trees before applying changes, but
> it's obviously a good idea.
You don't need to compare the trees if that's too much work. But I
definitely would first check the status of the target tree. Because if
there are local modifications, you would overwrite them later.
>> 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.
>
> Manual inspection of the modifications after the import. I haven't
> ever used svn_load_dirs.pl but I think it presents some sort of list
> of new verses deleted files and asks the user to line up those that
> correspond to renamed files?
>
> The more I think about it the less concerned I am about renames, at
> the end of the day all it gains is slightly better log history for
> directories that are generally imported from elsewhere anyway.
I agree.
>>> 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?
>
> Copying files from one part of a repository to another. Using either
> 'svn copy' or plain file overwrites.
>
> My repository looks like this:
> - Project1 - trunk - Source
> - Library1 - Api
> - Libs
> - Library1 - trunk - Source
> - Distrib - Api
> - Libs
>
> When a new version of the library is ready the headers and binaries
> are commited in -Library1-trunk-Distrib. That directory then needs
> to be mirrored into -Project1-trunk-Library1. It's not an svn
> external because I want control over when the project upgrades to
> the new version and I want the version to maintained when tagging
> etc.
>
> I haven't done this enough times to form a strong opinion whether
> I'd prefer this to use 'svn copy' or just the right-drag operation
> planned above.
May I suggest another approach here:
* include the library folder with svn:externals
* to avoid problems with which version of the library you're using, use
the '-rXXXX' flag in the svn:externals property.
For example:
on trunk, set svn:externals to
Library1 path/to/Library1/trunk/Distrib -r100
with r100 being the revision where you committed the library version 1.
If you then later switch your trunk to library version 2, just change
the 'r100' to 'r200' or whatever revision the version 2 was committed.
That way you avoid copies which aren't really necessary, and you also
avoid accidental changes to those library files.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Jun 24 12:34:38 2006