"Ph. Marek" <firstname.lastname@example.org> 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
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
> 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.
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
> 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
> 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.
www.collab.net <> CollabNet | Distributed Development On Demand
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Sep 20 05:07:23 2005