Re: the meta-data-versioning branch

"Ph. Marek" <philipp.marek@bmlv.gv.at> writes:
> > 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.

Merges from trunk would not destroy any information. After all, you
can always show the difference between the head of a branch and the
head of trunk, after such a merge. That difference is precisely the
code needed to implement the branch's feature.

> > 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.

Thanks!

> 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.

That is *hugely* clarifying, thank you for explaining this.

> > 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.

Yup, understood now, thanks.

> > 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.

Oh, I wouldn't be surprised :-).

> 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.

I haven't personally got the cycles to process the larger changes
right now, I have to concentrate on the small features (and even that
has to get put into a triage queue :-) ). But I'll save this mail,
and others can see it too.

Thanks for the overview, it helps a lot.

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org