On Tuesday 30 January 2007 01:56, Peter Dimov wrote:
> Standalone branches have their own repository. Bazaar also has the
> concept of a shared repository where multiple branches share the same
> revision store. With a shared repository when you branch within the
> repository you don't copy its revisions. You just refer to the ones in
> the shared store. If you branch to a standalone branch you need to copy
> all revisions.

We might have a problem using different terms for different things here.

A subversion repository in fact only represents one real branch (in bzr 
terms). Subversion 'branches' are only a convention, they are not first class 
objects. There is nothing in the repository representing the concept of a 
branch (or a tag). As trac was and is tightly connected to subversion, it 
currently also supports only one branch.

As such, there is per se no problem in supporting bzr and bzr revisions, as 
long as you use only one bzr branch.

Now, if trac had support for using multiple repositories, it could also 
support multiple bzr-branches. Whether these bzr-branches are standalone or 
compressed together in a shared repository, is imho not really relevant to 
trac, it's only an implementation detail.

> > A more severe problem for vc backends other than svn is imho the fact
> > that the vc api currently only supports a linear history, which means
> > that (from Trac's point of view) each revision can only have a single
> > ancestor. This is not the case e.g. for Monotone or Mercurial, and maybe
> > others.
>
> bzr keeps a linear revision history. Thus revious_rev would always work.
>  When you are at revision 50 and you merged another branch in, you
> commit revision 51. The previous revision of 51 is 50 but if you look at
> the changeset 51 you'll see it has two parent trees. You can browse to
> the other one from there.

What you describe is not a linear history. Revision 51 on that branch has in 
fact two parent revisions, 50 on that branch and 42 (or whatever) on the 
other branch.

Wouldn't it be nice, if trac could show a combined history of all revisions 
that led to the one you are looking at? 

Those problems can all be solved by having trac support (a) multiple 
repositories and (b) multiple parents per revision.

Regards,
Thomas

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac 
Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to