Mark Phippard wrote:
> On Fri, Apr 3, 2009 at 9:06 PM, Neels Janosch Hofmeyr <neels_at_elego.de> wrote:
[...]
>> (( Testing around, I found that it makes no practical sense to commit an
>> external when it has an explicit revision number. So, I for myself am
>> thinking it'd be good to a) handle both directory and file externals the
>> same way, by b) excluding them from commit recursion if and only if they
>> have a fixed revision number. Meaning that revision-less dir-externals would
>> be included in recursive commits, while "revision-ful" file-externals
>> wouldn't. It seems to cater for all the needs: If I want a patchy working
>> copy to commit in, I don't supply revision numbers and am working on HEAD.
>> Makes sense. If I want to have a fixated snapshot of something, I provide a
>> revision number and can't commit on it. Makes sense!
>> I'd even go as far as warning about any modifications made on externals with
>> a fixed revision number... ))
>
> FWIW, at the API level you can already do this. I think we only
> prevent it in the command line. In Subclipse we do all commits to
> externals from the same repository in a single transaction (always
> have) and it works fine. I *think* TortoiseSVN might provide this as
> an option.
Well, that should be a pretty easy job, then. What a bummer that no-one took
a look at it before releasing file externals in 1.6.0.
In any case, I think it would be good to disallow commits to file externals
with fixed revisions (e.g. by 1.6.1).
And then hopefully have a unified commit behaviour for file- and
dir-externals with a commandline switch by 1.7.
Does that sound about right, like it is likely to happen that way?
Thanks
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1545608
Received on 2009-04-04 22:02:31 CEST