centralized workflow and tracking upstream questions

[Tom Vaughan]

On Thu, Apr 3, 2008 at 1:52 PM, Neil Martinsen-Burrell <nmb at wartburg.edu> wrote:
> Tom Vaughan <tom <at> software6.net> writes:
>  which works because bzr assumes that files deleted by the OS are intended to be
>  removed.

Really? That's very interesting...

>
>  This is what I would do to track a vendor branch updated by zip files:

Thank you very much for the tutorial.

>  To do this with a centralized repository, you should be able to just create
>  site/vendor and site/mysite as (lightweight-) checkouts of some remote branch.
>  Then, each commit will propagate to the bound remote branch when it is locally
>  committed.

I think I did this correctly. This is one point I'm really perplexed
about. I'm sorry if this is covered elsewhere. But when I import the
first vendor version, and then merge that onto the trunk for the first
time, I wind up with all the files from the vendor branch added to the
trunk. At this point I still haven't checked them in (I did a `bzr
init ...` and a `bzr co ...`), but yet I can't check-in unless I
specify --unchanged. And after I do, I wind up with two new revisions.
Why? The first from branch nick "vendor," the second from branch nick
"trunk." When I do subsequent imports of other vendor releases, and
merge those onto the trunk I don't have to provide --unchanged, and
when I check-in I only wind up with one new revision.

>  I think that using tags as implemented in bzr (as labels for a specific
>  revision) is a better way to do things than making many separate branches in a
>  tags subdirectory as one would in subversion.  (A separate branch is required if
>  you want to make mixed-revision tags as is possible in Subversion.)
>  Real merging is exactly what bzr excels at, so I think that you should keep a
>  vendor branch as a single, real branch and your personal site as a separate
>  branch and merge between them at will.

OK. This will do the trick just fine.

Thanks!

-Tom