Hi,
On 2 Feb 2005, at 16:38, Tim Larson wrote:
If nobody objects within then next little bit, I will use:
At least it will be a simple standard, and we could do an
automated textual replacement if we feel the need later.
... and we can extend with more syntax later.
Sounds good to me ...
The oth
Hi,
On 2 Feb 2005, at 14:43, Sylvain Wallez wrote:
So I'm more than ok with formalizing a syntax for the Id string and
other metadata for later analysis, but using specially-formatted
comments. There used to be an xsldoc project at http://www.xsldoc.org/
that was producing javadoc-like documenta
Tim Larson wrote:
On Wed, Feb 02, 2005 at 03:43:19PM +0100, Sylvain Wallez wrote:
Tim Larson wrote:
I like the idea of having _some_ way to access the version
info in xml files, because someday we may have tools like
javadocs which would collect and display this info (think
for xml files li
On Wed, Feb 02, 2005 at 03:43:19PM +0100, Sylvain Wallez wrote:
> Tim Larson wrote:
> >I like the idea of having _some_ way to access the version
> >info in xml files, because someday we may have tools like
> >javadocs which would collect and display this info (think
> >for xml files like sitemaps,
Tim Larson wrote:
On Wed, Feb 02, 2005 at 02:39:49PM +0100, Sylvain Wallez wrote:
Conal Tuohy wrote:
What about a processing instruction?
This has the advantage over a comment that it can be retrieved
unambiguously with an XPath query: "processing-instruction('version')"
Questio
On Wed, 02 Feb 2005 14:39:49 +0100, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
> Conal Tuohy wrote:
>
> >What about a processing instruction?
> >
> >
> >This has the advantage over a comment that it can be retrieved unambiguously
> >with an XPath query:
> >"processing-instruction('version')"
> >
>
On Wed, Feb 02, 2005 at 01:49:35PM +, Tim Larson wrote:
> On Wed, Feb 02, 2005 at 02:39:49PM +0100, Sylvain Wallez wrote:
> > Conal Tuohy wrote:
> > >What about a processing instruction?
> > >
> > >
> > >This has the advantage over a comment that it can be retrieved
> > >unambiguously with an
On Wed, Feb 02, 2005 at 02:39:49PM +0100, Sylvain Wallez wrote:
> Conal Tuohy wrote:
> >What about a processing instruction?
> >
> >
> >This has the advantage over a comment that it can be retrieved
> >unambiguously with an XPath query: "processing-instruction('version')"
>
> Question is: do we
Conal Tuohy wrote:
What about a processing instruction?
This has the advantage over a comment that it can be retrieved unambiguously with an XPath query:
"processing-instruction('version')"
Question is: do we need that? IMO no, as I don't see valid use cases for
analyzing the version strin
Tim Larson wrote:
I personally do not like including a reference to the
revision control system, especially since we have already
experienced the data moving from one rcs system to another,
invalidating all the "CVS" comments. FWIW, I fully expect
another move in the future (not yet, don't get wor
Tim Larson wrote:
> On Wed, Feb 02, 2005 at 10:35:03AM +1300, Conal Tuohy wrote:
> > > Tim Larson wrote:
> > > > As part of my effort to keep whiteboard/forms mergeable,
>
> > > >Could we pick a style, and then I will make the files I
> > > >happen to touch match it?
> >
> > What about a process
On Wed, Feb 02, 2005 at 10:35:03AM +1300, Conal Tuohy wrote:
> > Tim Larson wrote:
> > > As part of my effort to keep whiteboard/forms mergeable,
> > >Could we pick a style, and then I will make the files I
> > >happen to touch match it?
>
> What about a processing instruction?
>
>
> This has
On Tue, Feb 01, 2005 at 01:20:10PM -0800, Ralph Goers wrote:
> Tim Larson wrote:
>
> >As part of my effort to keep whiteboard/forms mergeable,
> >
> >I am fixing a bunch of Id's and ran across a minor issue.
> >How do we want to mark the version in xml files? There
> >is quite a variety+possibili
Conal Tuohy wrote:
What about a processing instruction?
This has the advantage over a comment that it can be retrieved unambiguously with an XPath query:
"processing-instruction('version')"
Cheers
Con
Sure, that works too.
> Tim Larson wrote:
>
> > As part of my effort to keep whiteboard/forms mergeable,
> >
> >I am fixing a bunch of Id's and ran across a minor issue.
> >How do we want to mark the version in xml files? There
> >is quite a variety+possibilities:
> > CVS $Id$
> > SVN $Id$
> >
> > Version $Id$
>
Tim Larson wrote:
As part of my effort to keep whiteboard/forms mergeable,
I am fixing a bunch of Id's and ran across a minor issue.
How do we want to mark the version in xml files? There
is quite a variety+possibilities:
CVS $Id$
SVN $Id$
Version $Id$
version $Id$
@version $Id$
etc...
Cou
On Sun, Jan 30, 2005 at 11:21:30AM +0100, Sylvain Wallez wrote:
> Hi all,
>
> I found today some interesting things regarding how SVN handles keyword
> expansion.
As part of my effort to keep whiteboard/forms mergeable,
I am fixing a bunch of Id's and ran across a minor issue.
How do we want to
David Crossley wrote:
Tim Larson wrote:
Sylvain Wallez wrote:
The nice thing once all this has been fixed, is that SVN doesn't
consider as being modified a file where expanded keyword have been
replaced by their unexpanded counterpart. You can then use whatever
diffmerge tool you want to
Tim Larson wrote:
> Sylvain Wallez wrote:
> > The nice thing once all this has been fixed, is that SVN doesn't
> > consider as being modified a file where expanded keyword have been
> > replaced by their unexpanded counterpart. You can then use whatever
> > diffmerge tool you want to sync 2.2 an
On Sun, Jan 30, 2005 at 11:21:30AM +0100, Sylvain Wallez wrote:
> The nice thing once all this has been fixed, is that SVN doesn't
> consider as being modified a file where expanded keyword have been
> replaced by their unexpanded counterpart. You can then use whatever
> diffmerge tool you want
Niclas Hedhman wrote:
On Sunday 30 January 2005 18:21, Sylvain Wallez wrote:
So I came to the conclusion that SVN is smart (too much maybe) and only
replaces the content of an expanded keyword if this content matches some
well-defined and strict pattern.
or, are you sure that the svn:keywor
On Sunday 30 January 2005 18:21, Sylvain Wallez wrote:
> So I came to the conclusion that SVN is smart (too much maybe) and only
> replaces the content of an expanded keyword if this content matches some
> well-defined and strict pattern.
or, are you sure that the svn:keyword attribute is set for
Hi all,
I found today some interesting things regarding how SVN handles keyword
expansion.
In order to do some merging between 2.1 and 2.2 on CForms code, I wrote
a small shell script that replaces all expanded "$Id $" keywords by
the unexpanded "$Id$" in order to use the nice Eclipse diff
23 matches
Mail list logo
