On Tue, Aug 9, 2011 at 9:25 AM, Ron Wilson <ronw.m...@gmail.com> wrote:
> On Tue, Aug 9, 2011 at 10:58 AM, Richard Hipp <d...@sqlite.org> wrote:
> > The way I've *always* done things is:
> >
> > (1) ... edit files
> > (2) fossil commit -branch new-branch
> >
> > But I see many people want to do a 4-step process:
> >
> > (1) fossil branch new new-branch
> > (2) fossil update new-branch
> > (3) ... edit files
> > (4) fossil commit
> >
> > That seems like so much more trouble. What am I missing? Is it that
> people
> > are unaware that they can make edits that are destined to go into a
> branch
> > before that branch actually exists? Do I need to improve on the
> > documentation? Or does creating the branch first, before making file
> edits,
> > just fit most peoples mental model better? Are there some advantages to
> > creating branches in advance that I am missing?
>
> Besides how older VCSs have worked, many work places have a policy of
> doing work on branches, then merging the changes, later. By creating
> the branch first, there is no ambiguity of where new commits will go.
>
This is a good point. For development at work we are setting up git to allow
creating branches and limit who can check in on those branches (using
gitolite). Pre-creating branches is a hard requirement.
**soapbox mode - feel free to stop reading :) **
The list of things that chip away at making a case for using fossil in
serious work (lots of geographically distributed developers with minimal
communication channels and a complex project that contains many disparate
components) is not long, but does seem unnecessarily limiting:
1. ignores stored in db, no hierarchy, not revision controlled, propagated
with sync?
- minor but really annoying
2. symlinks not able to be stored (Windows support policy issue)
- can route around this one
3. no hooks (Windows support policy issue)
- deal breaker
4. mindshare (changing for the better every day but impacted by the above 3)
anything else?
Training time and ramp up on fossil is 100x faster than git and the
ticketing, wiki and web is absolutely fantastic but ignore files, symlinks
and hooks are basic features available in almost(1) *every* competing scm
and IMHO crippling fossil because of limitations of Microsoft Windows seems
unnecessary to me.
(1) Symlinks are the arguable exception here but on windows creating a file
with the link contents seems a fair fallback.
Just a random and unsolicited $0.02 precipitated by the incredible pain of
having to train myself and others on git. Something I'm not even 100%
certain I can successfully do for our team :-)
_______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
