James Henstridge: As far as unique identifiers for feed entries, it would be better to use the revision IDs ... This way twp branches that contain the same revision in their mainline history will get the same ID.
This makes a lot of sense, and actually helps solve a real problem for me.
James Henstridge: As far as unique identifiers for feed entries, it would be better to use the revision IDs ... This way twp branches that contain the same revision in their mainline history will get the same ID.
This makes a lot of sense, and actually helps solve a real problem for me. If everybody who is contributing to Venus maintained a feed, I could build a consolidated feed of everybody’s changes, and the act of people pulling changes from each other wouldn’t create duplicate entries.
Of course, I would create the consolidated feed using Venus. I’m sure that Joe Gregorio would approve.
Those that wish to pick up this change can do so from my branch.
Super!
I’ve updated my bzr-feed branch and keep a feed for my Venus branch.
BTW, speaking of self referential integrity: Where’s your bzr-feed bzr-feed? :-)
Where’s your bzr-feed bzr-feed? :-)
I also added some cosmetic improvements that you might want to pull.
P.S. You should be able to pull the changes instead of using merge.
Thanks!
And yes, I’m still not sure when it’s smarter to use pull or merge, but the latter gives me the option to review the changes before committing them.
I guess the next step would be to somehow include or reference diffs, but then of course it would perhaps be better to use a full web-view app for Bazaar.
I’m still not sure when it’s smarter to use pull or merge, but the latter gives me the option to review the changes before committing them.
OK, suggestion then: if you merge something that you are happy with, instead of committing it, do the following:
bzr revert bzr pull http://...
Occasionally, the pull will fail if a merge actually is required, but if that’s the case, simply redo the merge.
One extra command (two if there is a real need to merge), but at least the revision history is clean.
While what you’ve done is better, I’d suggest using the Bazaar revision ID directly in the entry ID. While your method works for the revision IDs that Bazaar generates now, the current format is not required. In fact if you use bzr-svn or the Arch importer, the IDs for the imported revisions will look quite different.
As for the question of when to use “pull” vs. when to use “merge”, it really depends on your intent. If you are just pulling someone else’s changes into your branch use “merge”. If you want to make your branch identical to their’s, use “pull”. Of course, if the two branches have diverged, then you’ll need to use “bzr merge”.
Note that “bzr pull” can change the mainline history of your branch if the other branch’s mainline history differs to your branch. This can also change the numbers assigned to some revisions (it does not change the revision IDs though). If that is a problem for a particular branch, then always use “merge” to bring in changes.
I’d suggest using the Bazaar revision ID directly in the entry ID.
Please make a concrete suggestion. What I would like to ensure is that the feed produced is valid, and the content of atom:id
MUST be an IRI.
I was thinking of some identifier that just has the revision ID appended to the end. I don’t have a good answer as to what the prefix should be.
The bzr-branchfeed plugin doesn’t prefix the ID with anything, which is incorrect as you say.
Perhaps a urn:
URI would be appropriate (assuming an appropriate namespace got registered).