On May 11, 2015, at 9:46 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:
>
> We have many customers with different requirements and firm restrictions
> on what can be shared between them, though we share as much as we can so
> that we're not duplicating effort.
In that case, I’d split your current repo into N+1 Fossil repositories. Each
customer gets their own private repo which links into the common code base
built from the main repo. The per-company repos might build static libraries
for linking into the base, for example.
This gives you complete privilege separation without giving up on code sharing.
This does make sharing code between repos more difficult, but that’s what
you’re after, isn’t it?
> a busy code line
> manager with many projects might just miss the fact that a developer
> checked something in directly to an integration branch.
Yes, and a busy HR department might miss the fact that Joe from Dept X always
prints to Dept Y’s printer, because it’s closer, and he’s lazy.
If you have an actual problem, i.e. one that causes a problem in the code base,
then you have a people problem. Joe’s manager talks to him, straightens him
out, tells him not to do it again. If Joe is worth keeping around, Joe will
heed this warning.
> it would also be good to make sure
> someone doesn't make a branch with the same name as something reserved
> for code line management or other administrative use.
Do you submit feature requests to your C/C++ compiler vendors asking for
variable and function naming convention enforcement, too?
This is a training issue. Tell your people what the naming convention is,
provide a reasonable rationale, and come down on people who violate it.
>>> - Restrict the naming convention of non-propagating tags
>>
>> This is less useful, since you can delete a tag and reapply it to
>> rename it.
>
> I'm sorry, but I am having a hard time seeing the point of your
> statement in the context of this discussion. If the naming convention
> of non-propagating tags is restricted, how does deleting and reapplying
> dodge the restriction?
You’re missing my point, which is that it is easy to fix a badly named tag:
delete the improper one, and apply a new one with the proper naming scheme.
As with all of this, you want to fix the problem two ways: Fix the immediate
problem, then fix the problem that caused the problem by talking to the
employee who perpetrated the bad tag.
> non-propagating tags indicating stuff
> like QA approval or release.
I would think that branches serve that need well enough already:
trunk
|
>------next-version branch
|
>------Joe’s experimental feature branch
QA signs off on Joe’s experimental feature by merging it into next-version.
When the release manager is happy with the state of the next-version branch, he
merges it into trunk.
A common variation is:
trunk
|
>------stable-version branch
|
>------Joe’s experimental feature branch
In this scheme, QA signs off on Joe’s experimental feature by merging it into
the trunk. That stabilizes over time, with experimental features being held
back during the stabilization window. Then when the release manager is happy
with the state of the trunk, he cuts a new stable version branch, allowing new
experimental features to be checked into the trunk again.
> the version
> description document can and should give the SHA-1 artifact ID of the
> official release check-in, if anybody can move tags around, it's not
> safe to trust the symbolic tags.
So use the symbolic tags for convenience, and *also* record the artifact ID as
“the truth.”
If it makes you happy, write a script that occasionally compares the current
repo state with an archival copy of the tag-to-ID mapping, to catch people
moving tags around. Additions are silently added to the archive, deletions and
changes cause alarums and havok.
> I won't disagree that this is a people problem, but in a large project,
> stuff like this can go undetected for a long time.
If it goes undetected for a long time because it doesn’t matter, then it
doesn’t matter.
If the fact of it going undetected for a long time causes the company actual
damage, then you have either hired an idiot or a saboteur, and you need to deal
with *that*, not demand that Fossil be proof against malicious attack or
ham-handed blundering by people you trusted with developer accounts on your
repo.
Don't depend on Fossil to fix your company’s trust and competency issues. Fix
your company’s trust issues, hire competent people, then use Fossil.
This may sound familiar to you:
http://thedailywtf.com/articles/source-history-information-tool
> Fossil only
> shows the original and the final changes, not the intermediates, so it
> can be hard to search for all superseded control artifacts in order to
> restore the desired version.
That’s just a UI issue. Someone *could* add a feature to Fossil that would let
you trace a comment’s change history.
Apparently, no one has needed to do so often enough that it’s been worth it to
them to add this feature to Fossil UI. Until that happens, I don’t think it
should be considered a blocking issue when choosing whether to adopt Fossil.
If you are one of those who will occasionally need this, but not so often that
you’d like to add this feature to Fossil UI, you can drag the info out of the
SQLite DB.
> requiring eternal vigilance over all branches,
> including those that haven't needed to be touched in years, is going to
> hurt Fossil's adoption in organizations like mine.
Um, have you actually *used* RSS? Branches that don’t change cause no RSS
updates, hence nothing appears in your feed reader. You can monitor thousands
of dead branches with zero incremental overhead, other than the time it takes
to keep pulling dead feeds.
Any decent RSS reader will let you group feeds in such a way that unexpected
changes to old dead branches will pop right out.
If you are uncomfortable relying on a human to monitor an RSS feed, it is easy
to write a program that consumes the RSS feed and sends out panicked emails
when closed branches get checkins.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
