Re: [TSVN] Non SVN or TSVN specific revprops

Molle Bestefich wrote:
> Simon Large wrote:
>> Molle Bestefich wrote:
>>> These are the major ones:
>>> - Commits to the repo becomes non-atomic :-(
>>
>> Did we discuss at some stage having an option to commit externals,
>> and possibly to do it atomically if it is in the same repository?
>
> I thought the message from Steve was that it's a Subversion problem
> and thus cannot be fixed in TSVN.

Subversion doesn't directly support committing externals, but we could
possibly do the legwork within TSVN and add the externals changes to the
list of changed files. If the externals are in another repo then we
would have to do N separate commits which gets a bit messy. Not
something to undertake lightly.

>>> - After tagging the code with 'svn cp', the shared files are not
>>> pinned at their current revision - they keep "updating inside the
>>> tag".
>>
>> Took me a while to work out what you meant here. The tag doesn't
>> change, but it points to something external which is not itself
>> tagged. Maybe we should scan for externals when creating a tag and
>> warn about that. Not sure that we can do anything about it though.
>
> The net effect is that I checkout a (unmodified!) tag, and I get
> different stuff from what I got last time I checked out that same tag.
>
> I see this as a Subversion problem, I don't think we can do anything..

No, I can't think of anything.

>> If you commit a WC containing externals, TSVN tells you that
>> they have to be committed separately. Conversely, updates always
>> update the externals too.
>
> Hopefully they will just be committed without having the user browse
> to each and every darn folder and clicking commit. At least that's
> what my TSVN does, which we happen to rely on a lot :-)

Huh? That's not what happens for me in 1.2.0 RC2. If I try to commit the
parent folder I get a dialog saying:
There are changes inside one or more directories which you have included
with svn:externals.
Those files are <b>not</b> listed for commit. You need to commit those
files separately.

>>> The workaround is to checkout (or was it export?) the shared files
>>> separately and then copy that WC/folder into one's project WC.
>>
>> You can used nested WCs, and they operate independently (although the
>> overlay status still propagates upwards).
>
> That's what I tried to say :-).
>
>>> Or just hack the entries file and remove the dir entry.
>>
>> If that is in the FAQ, tell me where and I will delete it straight
>> away. You should _never_ hack the entries file.
>
> That's not what I said, at least it's not what I tried to say..
> I'll try again:
>
> There's an entry in the FAQ which explains one way to get
> non-modifiable shared files working. Basically, check out the shared
> files separately, and then copy the checked-out WC into your project
> WC. This will do weird things to Subversion, causing it to leave the
> sub-WC alone.

This is a nested WC, and it is standard subversion behaviour. Same
effect as creating a new folder in your WC and checking out something
else into it.

> The same affect can be achieved by simply nuking the directory entry
> for the sub-WC from the "entries" file. The advantage of doing it
> this way is that the checkout operation is easier (and thus perhaps
> easier to explain to your team).

I think you are mixing up 2 different scenarios. That one was about a
repository folder which contains (say) 10 folders, of which I am
interested in 3. If I check out the top level I get all 10 projects.
There was talk about checking out the top level folder only and then
hacking the entries file so that when you update you get only the 3
projects you are interested in. But that is definitely not recommended
by us. If you really want to be able to update all 3 projects together,
creating a local project which pulls them in using svn:externals is a
better way to go. Otherwise just check out the 3 projects individually.

Simon

-- 
       ___
  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