Justus Pendleton | 1 Jan 23:39 2005
Picon

preliminary darcs implementation

I have a first pass at letting trac talk to darcs repositories.  It isn't
complete but seems to work for what I've done.  I've added infrastructure so
that other systems -- monotone, arch -- could conceivably be used as well, but I
haven't bothered with the backends for those.  Having trac use multiple
repositories shouldn't be too hard, either.

For those who want to take a look, the darcs repository of my changes is
available at http://www.ryoohki.net/~justus/trac and I have a tracd running at
http://www.ryoohki.net:8080 against a darcs repository.

What works:
- the Timeline view
- the Changeset view, although I haven't added in diffs yet
- the Browser view, but only for "head" and it is pretty slow right now
- tracd
- all of the stuff that didn't talk to subversion directly: Wiki, Tickets, and
Roadmap
- subversion access still works

What doesn't work:
- trac-admin.  to create a darcs repository you need to set up an env by hand

What I've done is create a new package trac.repository that has a factory
method.  Each backend has its own class and needs to support the API that is
loosely documented in Repository.py.  So I ripped out all of the svn specific
stuff and put it in trac/repository/Subversion.py, trying to clean up the
interfaces a little bit but generally leaving the code as it was.

There is also a new configuration option "repository" which has the format
repository = TYPE LOCATION
(Continue reading)

Brad Anderson | 3 Jan 07:39 2005

PostgreSQL Conversion

Hi all,

This weekend, I tinkered with a patch to allow Trac to work with a PostgreSQL 
database instead of SQLite.  It is just the beginning of what is required, 
but I got most modules to at least come up and render data.

http://trac.dsource.org/projects/test/wiki/PostgresqlPatch

Comments are welcome.

Cheers,
Brad

See also:
http://projects.edgewall.com/trac/ticket/126
http://projects.edgewall.com/trac/wiki/DatabaseBackend
Muness Alrubaie | 3 Jan 22:30 2005
Picon

Tags

I've implemented tagging support for Trac.  I was able to do so
without having to modify Trac itself and did the whole thing through
macros.

The implementation is documented at
http://dev.muness.textdriven.com/trac.cgi/wiki/tags .  Here's a
snippet:

-----------
Tags are like hierarchically organized wiki entries, however with them
you can categorize a wiki entry under multiple tags and not just under
one hierarchy. You can then search for wiki entries categorized under
a tag or a collection of tags. In other words, tags provide a faceted
classification system for the Trac wiki.

As an added bonus, tags are linked to the wiki entry of the same name,
allowing you to describe them explicitly under the wiki entry of the
same name. This allows for a flexible means for establishing the
context of wiki entries. Besides this, tags also make it incredibly
easy to create todo lists or indexes.

Tags don't have to be predefined. As long as there are wiki entries
categorized under a tag, it'll be automatically created.

Tags are similar to labels in gmail, tags in the social bookmark
manager, del.icio.us and the photo sharing site, Flickr and WikiMedia
categories. They are substantially different than the latter because
tags are intimately tied with wiki entries of the same name, whereas
WikiMedia Categories are just indexes.
-----------
(Continue reading)

Alexey Shamrin | 4 Jan 07:15 2005
Picon

Re: Tags

Hello Muness!

Your project looks nice. But I thought it would be interesting for you
to read about my initial feelings about it.

1. Why do use the term "tag" instead of (much better in my
opinion) "label"? It will more comfortable for Gmail users, I think.
Also you may use the term "category" in some places (see #3).

2. Your examples are confusing. The reason for this is that your
wiki names contain "/" too often. It's tempting to think that
this your use of "/" _is_ the use of tags. I would suggest to
give tag examples without "/".

3. When I tag some page (TagIt) it becomes "Tag:tag_name".
The better way I think would be something like the following:

This page belongs to the following categies: tag_name

or (if you like the term "tag" more)

This page is tagged under the following categories: tag_name

or something similar.

4. I don't really understand how "%" in TagIt is interpreted. 

Alexey

On Mon, 3 Jan 2005 16:30:06 -0500, Muness Alrubaie <muness@...> wrote:
(Continue reading)

Muness Alrubaie | 4 Jan 16:51 2005
Picon

Re: Tags

Alexey,

1) Some people prefer tag, others category, and others still label.  I
don't have a preference.  (The terms I think of is "overlapping
namespaces", but I don't think that'd ever be widely accepted.)  This
can be configurable so that people can use whichever terminology they
prefer.  Does that sound reasonable?

2) I started with organizing things hierarchically, hence the "/" all
over the place.  I think tagging/labelling/categorizing can do
everything hierarchies can do, but have not been inclined to actually
go ahead and make all hierarchical entries flat.  This may be the best
thing to do.  What would be nice if I had a whole bunch of content to
tag and see how to best do things.  (Labels with hierarchies or labels
with no hierarchies.)

3) See 1.  This can be configurable.

4) The "%" is being used in ListTags, not TagIt.  This goes back to
the hierarchical stuff.  By adding a "%" to the end of a topic, e.g.
"COMP313%", I match against "COMP313" and everything that is -
hierarchically - underneath it, e.g. COMP313/Week1, etc.

Again, this may simply be a non issue if I limited myself and stopped
using hierarchies.  So, instead of labeling a topic COMP313/Week1, I'd
label it COMP313,Week1.  So, if I need to query COMP313, I just do a
[[ListTags(COMP313)]].  For COMP313 Week1 entries a
[[ListTags(COMP313,Week1)]] would work.

I think that until we get experience with using labels in contrast
(Continue reading)

Christopher Lenz | 4 Jan 19:06 2005
Picon
Picon

Re: Tags

Hi Muness,

first, I think your work on tags in the trac wiki is pretty 
interesting. This is IMHO something that could go into Trac proper 
after the concept is worked out.

Am 04.01.2005 um 16:51 schrieb Muness Alrubaie:
> Alexey,
>
> 1) Some people prefer tag, others category, and others still label.  I
> don't have a preference.  (The terms I think of is "overlapping
> namespaces", but I don't think that'd ever be widely accepted.)  This
> can be configurable so that people can use whichever terminology they
> prefer.  Does that sound reasonable?

Please no, let's just agree on one term. While it's tempting to create 
options for every situation where different people have different 
opinions, it's the road to chaos ;-)

I personally prefer "tags", as used by Flickr and del.icio.us. "Labels" 
is okay.

> 2) I started with organizing things hierarchically, hence the "/" all
> over the place.  I think tagging/labelling/categorizing can do
> everything hierarchies can do, but have not been inclined to actually
> go ahead and make all hierarchical entries flat.  This may be the best
> thing to do.  What would be nice if I had a whole bunch of content to
> tag and see how to best do things.  (Labels with hierarchies or labels
> with no hierarchies.)

(Continue reading)

Chris Beck | 4 Jan 20:07 2005
Picon
Picon

Re: Tags

It is whispered that Christopher Lenz was heard, on or about 01/04/05 13:06 to say:
> subpages. For example from "SomePage" I should be able to link to 
> "SomePage/SubPageOne" simply by writing "/SubPageOne". Note that that 

That is confusing with current file-system heirarchies where /SubPageOne would imply something in a
different tree.  It would be a good idea to use a prefix symbol other than / (perhaps + ?, the fs standard of ./
is another option ) to indicate a sublink, but the use of "/" as a level separator is definitely good.
--
Chris Beck / Y.A.B.A. / Fungal Genomics / Concordia University / ext. 5791
People's Front to Reunite Gondwanaland
"Fight the Laurasian Separatist Movement!"
Paul Bennett | 4 Jan 21:19 2005

Version and milestone not being displayed as None

Under v0.7.1, when I added a new ticket, but didn't specify a version or milestone, they displayed as "None" in reports. After upgrading to v0.8, they now display as a blank field. All previously entered tickets still display as "None."
 
This wouldn't be a big deal, but when I look at a report that groups by milestone, the newly entered tickets sort separately (with a blank milestone) from the old tickets (with a None milestone).
 
Does anybody have an idea of how to fix this, or should I enter a bug report?
 
Thanks.
 
_______________________________________________
Trac mailing list
Trac@...
http://lists.edgewall.com/mailman/listinfo/trac
Muness Alrubaie | 4 Jan 20:29 2005
Picon

Re: Tags

On Tue, 4 Jan 2005 19:06:38 +0100, Christopher Lenz <cmlenz@...> wrote:
> Hi Muness,
> 
> first, I think your work on tags in the trac wiki is pretty
> interesting. This is IMHO something that could go into Trac proper
> after the concept is worked out.

Can we put a list together of what we should work out?  Or you can
feel free to post to the dev.muness.textdriven.com tags/Improvements
wiki entry.

> 
> Am 04.01.2005 um 16:51 schrieb Muness Alrubaie:
> > Alexey,
> >
> > 1) Some people prefer tag, others category, and others still label.  I
> > don't have a preference.  (The terms I think of is "overlapping
> > namespaces", but I don't think that'd ever be widely accepted.)  This
> > can be configurable so that people can use whichever terminology they
> > prefer.  Does that sound reasonable?
> 
> Please no, let's just agree on one term. While it's tempting to create
> options for every situation where different people have different
> opinions, it's the road to chaos ;-)
> 
> I personally prefer "tags", as used by Flickr and del.icio.us. "Labels"
> is okay.

I vote for tags as well.  Again, I don't care much.

> 
> > 2) I started with organizing things hierarchically, hence the "/" all
> > over the place.  I think tagging/labelling/categorizing can do
> > everything hierarchies can do, but have not been inclined to actually
> > go ahead and make all hierarchical entries flat.  This may be the best
> > thing to do.  What would be nice if I had a whole bunch of content to
> > tag and see how to best do things.  (Labels with hierarchies or labels
> > with no hierarchies.)
> 
> I see the value of hierarchical wiki names in easier linking to
> subpages. For example from "SomePage" I should be able to link to
> "SomePage/SubPageOne" simply by writing "/SubPageOne". Note that that
> improves both the readability and the writability of long page names,
> also compared to a flat namespace where I'd have to write
> "SomePageSubPageOne". (This sort of shortcut linking isn't currently
> implemented in Trac, but I really think it should be.)

Agreed.  However, I think Chris Beck is right.  "/" would be weird. 
"./" makes more sense to me.  I've started implementing this as a
macro.

I am already using shortcuts in labels. "." refers to self and .0
refers to top hierarchical element (SomePage in "SomePage/SubPageOne")
for example.  Maybe we should create a list of shortcuts and make them
work both in wiki references and labeling.

An added advantage of using shortcuts is easier refactoring.

> 
> Generally I think tags/labels are often used in addition to hierarchy
> for organizing information.

Using them together makes sense.  Hierarchies are for more obvious or
primary classifications.  Labels do everything else.

> 
> One thing I wonder about is whether tags should really be limited to
> wiki pages. Why not allow tagging of e.g. tickets and changesets?
> Possibly replacing the already existing keywords for tickets?

I've thought of that.  Since I was new to Trac I really haven't had
much of a chance to explore the API it exposes to see if tickets and
changesets could be similarly tagged.

Also does the reverse make sense: should we allow using a ticket as a tag?

> 
> Cheers,
> Chris
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
> 
> 

Muness

--

-- 
See my blog at http://muness.blogspot.com
Christopher Lenz | 5 Jan 00:29 2005
Picon
Picon

Re: Tags

Am 04.01.2005 um 20:29 schrieb Muness Alrubaie:
> On Tue, 4 Jan 2005 19:06:38 +0100, Christopher Lenz <cmlenz@...> 
> wrote:
>> Hi Muness,
>>
>> first, I think your work on tags in the trac wiki is pretty
>> interesting. This is IMHO something that could go into Trac proper
>> after the concept is worked out.
>
> Can we put a list together of what we should work out?  Or you can
> feel free to post to the dev.muness.textdriven.com tags/Improvements
> wiki entry.

I think this thread is okay for working out the concept.

>> Am 04.01.2005 um 16:51 schrieb Muness Alrubaie:
>>> Alexey,
>>>
>>> 1) Some people prefer tag, others category, and others still label.  
>>> I
>>> don't have a preference.  (The terms I think of is "overlapping
>>> namespaces", but I don't think that'd ever be widely accepted.)  This
>>> can be configurable so that people can use whichever terminology they
>>> prefer.  Does that sound reasonable?
>>
>> Please no, let's just agree on one term. While it's tempting to create
>> options for every situation where different people have different
>> opinions, it's the road to chaos ;-)
>>
>> I personally prefer "tags", as used by Flickr and del.icio.us. 
>> "Labels"
>> is okay.
>
> I vote for tags as well.  Again, I don't care much.
>
>>> 2) I started with organizing things hierarchically, hence the "/" all
>>> over the place.  I think tagging/labelling/categorizing can do
>>> everything hierarchies can do, but have not been inclined to actually
>>> go ahead and make all hierarchical entries flat.  This may be the 
>>> best
>>> thing to do.  What would be nice if I had a whole bunch of content to
>>> tag and see how to best do things.  (Labels with hierarchies or 
>>> labels
>>> with no hierarchies.)
>>
>> I see the value of hierarchical wiki names in easier linking to
>> subpages. For example from "SomePage" I should be able to link to
>> "SomePage/SubPageOne" simply by writing "/SubPageOne". Note that that
>> improves both the readability and the writability of long page names,
>> also compared to a flat namespace where I'd have to write
>> "SomePageSubPageOne". (This sort of shortcut linking isn't currently
>> implemented in Trac, but I really think it should be.)
>
> Agreed.  However, I think Chris Beck is right.  "/" would be weird.
> "./" makes more sense to me.  I've started implementing this as a
> macro.

/SubPage is a convention I know from UseMod (see 
http://www.usemod.com/cgi-bin/wiki.pl?UseModWiki). MoinMoin uses a 
similar convention described at 
http://moinmoin.wikiwikiweb.de/HelpOnEditing/SubPages. Using "./" 
actually implies linking to a page at the same level, not a sub-page. 
The basic problem here is that normal wiki names are absolute 
references, unlike file paths where absolute references always start 
with a slash (or drive letters on mediocre operation systems ;-) ).

> I am already using shortcuts in labels. "." refers to self and .0
> refers to top hierarchical element (SomePage in "SomePage/SubPageOne")
> for example.  Maybe we should create a list of shortcuts and make them
> work both in wiki references and labeling.

Not sure I understand... in what context are you using "." as shortcut?

> An added advantage of using shortcuts is easier refactoring.

Agreed.

>> Generally I think tags/labels are often used in addition to hierarchy
>> for organizing information.
>
> Using them together makes sense.  Hierarchies are for more obvious or
> primary classifications.  Labels do everything else.
>
>> One thing I wonder about is whether tags should really be limited to
>> wiki pages. Why not allow tagging of e.g. tickets and changesets?
>> Possibly replacing the already existing keywords for tickets?
>
> I've thought of that.  Since I was new to Trac I really haven't had
> much of a chance to explore the API it exposes to see if tickets and
> changesets could be similarly tagged.

There's not much of an actual "API" exposed, really. But if tags are to 
be built into Trac as a core concept, it *might* make sense to support 
the concept throughout, not just for wiki pages. It's a pretty blurry 
idea at this point, but it might make more sense when tags start being 
used in practice.

> Also does the reverse make sense: should we allow using a ticket as a 
> tag?

Interesting... so you could e.g. mark wiki pages as being related to a 
ticket by tagging them with the ticket ID?

I really need to check out how you're using tags more closely.

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de

Gmane