> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of
> Christopher Lenz
> Sent: mardi 7 février 2006 12:38
> To: trac-dev@lists.edgewall.com
> Subject: Re: [Trac-dev] vc-refactoring branch step 2
>
>
> Am 07.02.2006 um 12:09 schrieb Christian Boos:
> > The items I want to address this time are:
> > * fixing #1830 (Repository subsets have to be fully self contained)
> > For this, I think returning 'None' in place where we used
> > to raise a 'TracError: no such changeset or no such node'
> > would be enough. Of course, many places in the code would
> > have to be adapted to handle this situation, so I guess this
> > is potentially disruptive.
>
> So basically you just check for None instead of catching an exception?
>
> On a related note, we really need more specific exception types in
> the versioncontrol layer, like:
>
> * NodeNotFound
> * RevisionNotFound
> * etc (others?)
>
> > * reintroduce the support for additional changeset properties
> > ([2649] and adding Changeset.get_properties() method)
> > * reintroduce the support for tags and branches
> > ([2648] and adding Repository.get_tags() and
> > Repository.get_branches()).
> > Tag and branch support in svn could be added by using a
> > [subversion] configuration section, where tags and branches
> > could be listed (defaults would be e.g. tags/* and branches/*).
>
> I'd omit the SVN stuff for now and just provide tags/branches
> support
> for those repository types that have a tag/branch dimension that is
> separate from the directory structure.
>
> > * make the changeset link syntax more tolerant (at least allow
> > hexadecimal changeset numbers)
> >
> > When this is done (should not take long),
> > this could eventually be merged back.
> >
> > Then, some more important changes:
> > * rework the interaction with the cache.
> > The cache could be used for more operations:
> > * for the Repository.get_changes() (changesets in a
> > given period of time)
> > * for the Repository.get_path_history (maybe)
> > * for the Repository next_rev and previous_rev (maybe)
> > * for the Node information (currently not used, but would
> > be crucial for "flat" versioning systems like mercurial)
>
> Can you please elaborate on that last point?
>
> > * (eventually) rework the TracLogRevision to support multiple
> > ''branches'' (similar to gitk/hgk)
> >
> > Also, there shouldn't be much (if any) interference with
> > the work done on other branches (WSGI, anti-spam, etc.)
>
> Overall, +1
>
> What I'd prefer for the implementation approach would be to order
> changes so that those *absolutely required* for *minimal*
> support for
> a VCS such as Mercurial go first (I think this is only cache and
> changeset link patterns). Those changes that are needed for *good*
> support for Mercurial/etc go next. Plus we should try to get
> feedback
> from the folks who worked on Darcs/BazaarNG/Perforce support.
>
> Cheers,
> Chris
> --
> Christopher Lenz
> cmlenz at gmx.de
> http://www.cmlenz.net/
>
> _______________________________________________
> Trac-dev mailing list
> Trac-dev@lists.edgewall.com
> http://lists.edgewall.com/mailman/listinfo/trac-dev
>
Hi,
I work on the Perforce plugin.
It's a "minimal" integration of Perforce:
- no cache
- no perforce attribute support (similar to svn properties)
I use the trac branch made by Christian some time ago, it works very well for me, Thanks !
The SCM model of Perforce is very near to subversion's one, so i have no additional
items to add to the list.
Indeed, i'm agree with Christopher to have the basic functionnality first.
My only wish is to have the version control plugin ASAP in the
next official release.
Many thanks to Trac developpers, it works very well !!!
Thomas Tressieres
Ce message et ses pièces jointes (le "message") est destiné à l'usage exclusif de son destinataire. Si vous recevez ce message par erreur, merci d'en aviser immédiatement l'expéditeur et de le détruire ensuite. Le présent message pouvant être altéré à notre insu, CALYON Corporate and Investment Bank ne peut pas être engagé par son contenu. Tous droits réservés.
This message and/or any attachments (the "message") is intended for the sole use of its addressee. If you are not the addressee, please immediately notify the sender and then destroy the message. As this message and/or any attachments may have been altered without our knowledge, its content is not legally binding on CALYON Corporate and Investment Bank. All rights reserved.
_______________________________________________ Trac-dev mailing list Trac-dev@lists.edgewall.com http://lists.edgewall.com/mailman/listinfo/trac-dev
