On Thu, Oct 20, 2011 at 11:31:01AM -0700, Mike Meyer wrote:
> 2011/10/20 Lluís Batlle i Rossell <[email protected]>
>
> > On Thu, Oct 20, 2011 at 11:07:23AM -0700, Mike Meyer wrote:
> > > On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment <[email protected]>
> > wrote:
> > > How about an having a way to flag files - when created - as "read-only"
> > or
> > > some such. (I think someone else may have suggested this). Such files
> > would
> > > be checked out read only, and would require a "-force" to commit. A new
> > > "readonly-glob" setting would help - causing files that matched it to be
> > > flagged as such along the way.
> > >
> > > The goal is not to have locks as such, but to alert people to the fact
> > that
> > > a file requires out-of-band communications before it gets changed and/or
> > > committed.
> >
> > It looks very nice, but that should be able to be set on past checkins too,
> > the
> > same way you edit checkins to change tags. Otherwise, "when created" sounds
> > very
> > limiting.
> >
>
> Two issues. One is that it really belongs on files, not checkins. The other
> is that you have to figure out what to do about files derived from that one
> when you set the flag retroactively.
I'm still not sure on what would I prefer. I still have 'artifacts' in mind.
> Hmm - maybe the "readonly-glob" setting is enough? If it's not set, you get
> the current behavior. Otherwise, you check it when you pull files out of the
> repository (to set them read-only) or commit (unless -force is on). That
> also fixes the question of retroactively setting the flag. But it might be
> to expensive.
I think it's becoming more and more a "quick hack". :)
Listing some features that people may expect for "needs-lock" files:
1. Avoid editing what someone already edited in another checkin,
and can be merged with the branch where you plan the edit.
2. Avoid editing what another is already editing in the working dir,
and can be merged with the branch where you plan the edit.
For the case 2, team communication can be ideal. But for case 1, also memory
plays a role, so team communication may not be the perfect solution. :)
I'd expect an optional locking system to provide an alert for both cases. But
maybe it is expect too much. But in five minutes I may think different. :)
Regards,
Lluís
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
