On Wed, Mar 14, 2012 at 3:13 PM, Christopher Berardi
<cbera...@natoufa.com>wrote:

> A thought that occurred to me that would be a nice feature to compliment
> our hopefully forthcoming per-branch push/pull implementation is the
> ability to do the same, but using a branch tag as the key.
>
> Take the following scenario as an example. A company has a product that
> is being worked on by a team of x developers. Each of the developers has
> a number of private branches where they do experimentation. The team
> shares a number of branches that are just for them (semi-public). And
> the company has set up a public facing (i.e., cgi website) branch for
> each of their clients for issue tracking and support (maybe 2 branches,
> one for issue tracking and another common one for documentation). It
> would be real nice to be able to assign a tag to each branch and then
> push/pull based off of that. So a developer can push/pull on tag =
> 'team' to work with the team's common branches, or pull tag = 'clients'
> to get an update on all the latest bug reports, or after having fixed a
> number of bugs for different clients, push tag = 'clients' to update the
> public side of things.
>
> I guess you could view this as just a grouping/convenience mechanism for
> the explicit branch push/pull, which hasn't even been implemented yet
> (but, that many of us hope will be soon).
>
>
>
Hi,

I'm the slowpoke working on this feature. Fortunately for you, I considered
exactly
such a situation. Since a branch is essentially just a tag that propagates
to descendants, any
tag that has that property should work. You will have to create such tags
via the
commandline since the web interface doesn't appear to have a way to create
propagating tags.

-B
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to