On Wed, Jun 4, 2014 at 2:07 PM, Nico Williams <n...@cryptonector.com> wrote:
> On Wed, Jun 4, 2014 at 12:30 PM, Stephan Beal <sgb...@googlemail.com> > wrote: > > On Wed, Jun 4, 2014 at 7:25 PM, Nico Williams <n...@cryptonector.com> > wrote: > >> > >> To be truly useful it has to be possible to [selectively] push/pull > >> bookmarks. > > > > > > If that's the case then they really provide no benefits over propagating > > tags (which are versioned), but note that Fossil cannot selectively > > See my notes about the differences between tags and branches in git, > the most important of which I'll repeat and expand on here: > > - when you checkout a tag and then commit something, the tag doesn't > move with the HEAD of your workspace -- you're in detached HEAD mode > when you checkout a tag > Like a non-propagating tag. > > - when you checkout a branch and you commit something, the branch's > HEAD moves with the HEAD of your workspace. > Like a propagating tag. So what extra do you get from the Git approach? I mean other than having a separate "detached HEAD mode" which behaves differently from normal operation and might leave you with orphaned check-ins that get purged during a cleanup? So right now in the SQLite repository, the latest check-in has three separate tags: "version-3.8.5" is a unique non-propagating tag. Whenever you do "fossil co version-3.8.5" you always get that particular check-in. "release" is a non-unique non-propagating tag. Whenever you do "fossil co release" you get the most recent release. "trunk" is a propagating tag. Whenever you do "fossil co trunk" you get the latest check-in on the trunk branch. If you were to check-in a new change, the change would inherit only the "trunk" tag, not the "version-3.8.5" nor "release" tags. -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
