On Tuesday 13 September 2005 17:23, kfogel@collab.net wrote:
> Hi, Phil Marek. Erik Huelsmann and I were talking about ways to get
> the meta-data-versioning branch resolved. By "resolved" I mean: sort
> out exactly what features are in the branch, move to trunk those that
> can be moved to trunk, and retiring the branch -- after all, having a
> long-lived branch was never the goal here.
Fine!
> It seems the branch does
> not receive regular updates from trunk, so it's missing numerous
> bug-fixes and enhancements by now.
No. It was done simply to illustrate the differences needed to get this
features working - any merge from trunk would've destroyed the clean
separation.
> I can see that the branch is really two branches:
>
> * owner-group-mode
> * text-time
>
> In addition, it appears that the owner-group-mode branch has grown at
> least one other independent feature: support for multi-line directory
> autoprops, as you mentioned in a response to Martin Fuchs recently in
> the "Feature request: svn ignore" thread on users@ (you pointed him to
> http://svn.haxx.se/dev/archive-2005-03/0949.shtml).
Have a look at
http://marc.theaimsgroup.com/?l=subversion-dev&m=111459962412224&w=2
There are patches for 1.2.0rc2 splitted out.
My work can be divided into 4 elements:
a escape-seq: allows escape-sequences in the config-file (standalone)
b dir-auto-props: gives automatic directory properties (needs escape-seq)
c mtime: version modification time (standalone)
d owner-group-mode: versions meta-data. (includes c, should have b)
The mtime-branch is only c.
The o-g-m-branch is _only_ d - without b, as this is optional.
In the above mentioned mail you see (a), (b), (c+d) splitted out.
> We really shouldn't be mixing different new features in the same
> branch, if possible. It's much better to get a small new feature into
> trunk and then port it over to the branch, if the branch's larger
> purpose depends on it.
>
> Aside from the above, are there any other new features in either
> sub-branch? We're looking for things that can be cleanly separated
> out and incorporated into trunk. Breaking stuff out to trunk will
> require some effort, but it's worth it. Otherwise the features just
> languish on the branch.
Please see above.
> To get developer consensus on anything, however, the first thing we
> need are some design descriptions, explaining the why-and-how of each
> feature. Erik said he'd be willing to work with you on those, if
> you're unfamiliar with the process.
>
> We should probably start with the smallest feature, which would be the
> directory auto props, I guess. The easiest thing to do would be to
> develop an independent patch against trunk for it, and post that with
> a log message and any other necessary supporting materials.
That would be escape-seq - and there's already a standalone patch for that.
> Following that, we should try to get a consensus on the design for the
> rest of the meta-data-versioning branch, and integrate those features
> into trunk (insofar as consensus permits). When all that's done, we
> should retire the branch.
>
> I've CC'd Erik. Also Philip Martin, since I think he's been following
> the branch and would be interested in this conversation. Of course,
> we should take this discussion public (on dev@) as soon as we can,
> assuming you're okay with the general plan.
Fine by me.
> Thoughts? This all depends on you -- on you having the patience to
> produce those design documents and discuss them with the developer
> community. You should expect this process to take as much time as
> coding did; that's normal, nothing to be worried about.
What - two and a half years? :-) That's an awful long time.
> The stuff in branches/meta-data-versioning/README.TXT is a good start,
> but it is only an overview, and it mixes the two sub-branches into
> one, which makes it harder to figure out what functionality is where.
> Also, as you note, it does not specify how conflicts are handled, and
> the functionality does not always work as designed (as per note "[1]").
> We need to figure out where the bugs are before this can be merged.
They should be pretty stable by now. At least I've never heard a complaint by
any of the (at least) two dozen people which mailed me directly for this
feature, and I'm using it too - we have made ~2100 revisions with a
owner-group-mode-subversion, and had no problems.
> Whatever happens, that the current situation is not tenable in the
> long term. We can't have a branch with a partially-completed features
> sitting around, with no long-term plan to merge it to trunk. This
> will only confuse users. We need to do _something_ to fix this :-).
That's right. Then I wouldn't have to answer _the question_ (on dev@, or
users@) every two weeks ;-)
> For convenient reference, I've included all the log messages for the
> branch at the end of this mail.
Thank you, but not needed.
As people standing right in front of something can never see it fully, or
(other way round) you have to have some distance, I'd beg people to read
the various commit-logs I've written (see also
http://svn.haxx.se/dev/archive-2005-02/0005.shtml,
http://svn.haxx.se/dev/archive-2004-11/att-0411/01-patch-tstamp-svn1.1.1-2.patch,
and last but not least the issue 1256), and tell me what's missing.
The IMO only point which has still to be discussed is what to do if a file
get's checked out with owner X, get's locally chown()ed to Y, and updated to
Z.
Regarding the modification time there was a discussion not long ago.
I believe it's best (and simplest) if a file about to be committed (because of
text modifications) just has it current values sent along.
So if I check out on date A, do a merge with at time B, then commit would send
B (the time of the merge) along.
Note: For development purposes the whole discussion about timestamps and make
may arise again.
My patches were mostly thought to be used for non-make-situations, ie. where
no actions were done based on the timestamps.
Perhaps there's need to define another property, which tells to store the
mtime as currently, but *don't* set it *on update*. export and checkout may
use it without problems; and if an updated file get's changed, on commit the
modification time (sic!) is sent - which would be correct, too.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 14 07:49:38 2005