Hi Thomas,
Thanks for the reply!
Thomas Moschny wrote:
> 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.
A lot is done with branches in bzr and having only a single branch in
trac not at all feasible. Below are some example directory structures, I
hope they help clear terminology differences:
/ bzr shared repository
trunk bzr branch (the official one)
releases normal dir (unversioned)
x.y.z bzr branch
...
developers normal dir (unversioned)
john either normal dir or a (nested!) bzr shared repository
john-dev branch
The above does work with trac+bzr, so trac+bzr does support multiple
repositories. Another scenario that would work with trac+bzr:
/ normal dir (unversioned)
project1 bzr shared repository
trunk bzr branch
...
project2 bzr shared repositroy
trunk bzr branch
...
developers normal dir (unversioned)
john shared repository
john-dev 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.
IMHO implementing multiple repositories is the sole responsibility of
the vcs backend. As you see trac+bzr provides this functionality. All we
need to do in Trac is provide both the path and the revno. I'm also
quite sure it would be possible to implement the svn backend to support
multiple branches just like bzr does.
I guess the following would work with svn:
/ normal dir (unversioned)
project1 svn repository
trunk svn versioned dir
...
project2 svn repository
trunk svn versioned dir
...
For that to work the svn backend would need both the revno and the path
to know where to forward the request. Actually I can imagine that for
project1 and project2 you create two separate SvnRepository objects and
have SvnRepositryFacade, which also implements versioncontrol.Repository
and delegates calls depending on the path prefix. What do you think?
Of course the additional support we would need from Trac is the ability
to have different milestones, versions and tickets for each project. I
remember reading a ticket proposing that...
>> 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.
Yes, you are right! It is not really linear but each revision you commit
in the branch goes in the revision history (which is just a list) and it
gets assigned the next revno. If we are at 50 and we merge and commit
we'll be at 51. So from the timeline point of view the previous rev
would be 50. Generally, you are right, 51 has two parent revisions: 50
and 44.2.3. Now, 44.2.3 is also a revision from the *same* branch. Once
you pull the new revisions from the other branch you assign them new
dotted revnos (but don't ask me how exactly they are chosen).
BzrChangesets.get_properties() returns not only date, message, author
but also the list (with hrefs) to the parent revisions. For the above
case you'll see the links to [50/branch] and [44.2.3/branch], so you do
have the option to browse both parent revisions.
> Wouldn't it be nice, if trac could show a combined history of all revisions
> that led to the one you are looking at?
Yes, definitely! A graphical display would be an especially great thing!
Can you provide some references to past discussions?
> Those problems can all be solved by having trac support (a) multiple
> repositories and (b) multiple parents per revision.
I just checked #2086 and I agree that revision should have a member
either base_path, or branch, or repo, or whatever. Each backend could
decide for itself what it needs. Then multiple branches/repositores/etc.
could completely be implemented in the vcs backend.
Looking forward to any comments!
Regards,
Peter
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
