Mark Phippard wrote:
> On Sat, Apr 4, 2009 at 4:02 PM, Neels Janosch Hofmeyr <neels_at_elego.de> wrote:
>> 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.
>
> How do file externals work? I thought they did process as commits?
> Since they are really just switched paths in the same repos, it seems
> like it would anyway. Did you mean why did someone not do the same
> for directory externals?
Yeah, I think it's not good to have file externals behave differently from
directory externals. On top of that I think that any externals that aren't
on a fixed revision should be allowed to commit as if they were normal.
But first of all I think file and dir externals should behave the same. The
only thing that distinguishes them on a UI level is the node type that the
URL happens to point at.
>
>> In any case, I think it would be good to disallow commits to file externals
>> with fixed revisions (e.g. by 1.6.1).
>
> Yes, we do not try to do that in Subclipse, but it does seem a
> reasonable idea. Perhaps the items ought to even be made read-only in
> the filesystem?
IMHO, categorically refusing to accept changes on externals with fixed
revisions would be enough. While I wouldn't object making them read only on
the file system either, as I don't see a good reason against it (yet).
>
>> 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?
>
> I'd be in favor of it, but I have a feeling you will get resistance to
> allowing the command line to commit directory externals.
While I'm getting involved in the discussion, I'm actually not trying to
push this, nor am I going to work on it in the near future -- I'd still like
to take a shot at diff first.
(but, if a company out there wanted to hire elego to do externals, I
probably would.)
I'm actually still trying to probe the general opinion on externals and find
out which direction it is likely to take: will file and dir externals behave
in a unified manner some day, or will they always be different.
~Neels
--
Neels Hofmeyr
elego Software Solutions GmbH
http://elego.de
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1545831
Received on 2009-04-04 22:41:51 CEST