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.
> > - 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..
> > Futhermore, a minor point (IMHO):
> > - A few people have complained about not being able to tell TSVN to
> > disallow commits to shared ('svn:external'ed) code.
>
> Have they?
Most recently it was requested by Sebastian Paul in a thread named
"Feature Request". I remember it has been discussed before that, I can
try and dig up another thread if you want me to..
> 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 :-)
> There might be scope for a new option (did I say that word?) for
> committing externals:
>
> Commit externals:
> ( ) Always
> (*) Ask me
> ( ) Never
If that's possible, that looks good to me.
We would keep it at 'Always' at all times, Sebastian Paul and others might
choose to use 'Never'. I still think that 'Never' is a pretty bad option,
but others might disagree. I've never seen anybody requesting "Ask me"
before now, but I might have missed something.
> > 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.
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).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu May 26 16:01:57 2005