At 11:45 AM -0400 7/11/08, Mark Phippard wrote:
>On Fri, Jul 11, 2008 at 11:37 AM, Ben Collins-Sussman
><sussman_at_red-bean.com> wrote:
> > Given that we've allowed a user to maintain a branch for this
> > feature for *years* -- without allowing him to merge the
> > feature -- our actions speak louder than words!
> >
>> I'm fine for reopening the debate; we should first examine why
>> exactly we've kept this branch in stasis for so long. If we don't
>> like the design, what would a better design be?
>
>Having used other version control systems that have this feature, I
>always thought Subversion should have it too. My problem with this
>has always been the design. I do not think you can do this feature
>properly on top of Subversion's repository today.
>
>Using a versioned property sucks. That means you have to carry
>around the property information in the working copy and every commit
>in theory needs to update it. This fouls log and diff etc..
>
>In theory revision properties could be used, but do we really want
>an import of 10,000 files sticking all of that data into revision
>properties? In addition, we do not have any great ways to access that
>data and it would add a lot of extra overhead during checkout/update
>operations to go find this information in the revision properties.
I'm also wondering how a versioned-property like this would be
handled when doing merges. Disclaimer: I've done very little with
merge-tracking, so the problem here may be my own ignorance. But I
assume you wouldn't want to merge the last-mod time from one branch
to another one.
--
Garance Alistair Drosehn = gad_at_gilead.netel.rpi.edu
Senior Systems Programmer or gad_at_freebsd.org
Rensselaer Polytechnic Institute or drosih_at_rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-14 21:38:21 CEST